Re: [Json] Adding integers to JSON (Re: JSON Schema Language)

[Austin Wright <[e-mail]>]

> On May 8, 2019, at 09:59, Carsten Bormann <[e-mail]> wrote:
> 
> On May 8, 2019, at 18:07, Nico Williams <[e-mail]> wrote:
>> 
>> That's an interop bug.  They should fix it.
> 
> It also nicely demonstrates the law of inevitable extensibility.
> 
> JSON was designed not to provide extensibility.  Ever.
> Radical, but a well motivated idea at the time.
> 
> Now people did not want to accept that.
> They wanted to extend the JSON data model with the distinction between two number types.

Who’s “they”? There’s only two uses of “integer” in relation to JSON that I’m aware of:

1. Implementations that parse JSON documents into a pre-defined structure, and will raise an error if the struct cannot store the lexical data (for example, putting a null into a int64_t, or an object into a char*).

2. JSON Schema, which defines integer as a strict subset of “number”. (It’s not even a data model type, it’s a special case for the “type” keyword that means the same as `{type:”number”, multipleOf:1}`)

Neither of these “extend" JSON, because JSON does not impose any requirements on how implementations parse numbers. My reading of RFC8259 allows implementations to differentiate between `3` vs `3.0` vs `3.00`.

Nonetheless, JSON Schema specifies that numbers are mathematical, so `10.0` would still be considered an integer. Likewise, I think parsers should ignore excess precision if it doesn’t change the mathematical value. But this is entirely a choice based on how most implementations work; rather than what JSON seems to allow. For example, scientific software might store significant figures such that `10.0` is considered less precise than `10.000`. In my reading of RFC8259 and ECMA 404, this is perfectly legal, but JSON Schema makes no distinction for validation purposes (i.e. there would be no way to assert “number must be at least this precise”).

> 
> The law of inevitable extensibility says:
> 
> # If you don’t provide an extension point, somebody will.
> # They will shove their extension into any crevice available.
> # (And your up to now rock-solid design breaks.)
> 
> The crevice here was that there are many ways to express the number 3: 3, 3.0, 3e0, 0.03e2, 300e-2 etc.  We can give some of these expressions different semantics than the other.  Voila.  Extensibility achieved.  Brittleness added.
> 
> I have seen the law of inevitable extensibility applied to:
> 
> — duplicate map keys for adding comments to JSON.  Some people believe:
> 
>  { “postcode”: “This is a comment about the post code 4711”,
>    “postcode”: 4711 }
> 
>  is a valid way to extend JSON with comments.  (Because their implementation happens to ignore map keys that are invalidly used again later, which is not a given.)

Certainly, this is not interoperable. But it is legal: RFC8259 merely says documents “SHOULD NOT” use multiple keys, and allows different implementations to handle it differently. ECMA-404 specifically says there’s no limits on string names, even repeated names (ECMA 404 is the document referenced by ECMAScript, though that specifies an algorithm that ignores repeated keys.)

For this reason, JSON Schema does not have any features dealing with repeated keys or their order (specifically, the data model specifies that objects are treated as an unordered string to value mapping), this is another artistic license that favors uniformity over supporting the complete lexical space of JSON.

> 
> - unnecessary escaping for ascribing some special semantics.  Say, if a string starts with “\u0073” and not with the equivalent “s”, this is supposed to mean the string has some different semantics (e.g., the rest is a base64url encoded byte string as opposed to what would normally be a text string, or a type tag, or…).

While JSON strongly implies these two forms must be considered the same thing, note this isn’t true for all formats. Namely, %2F is not the same as a forward slash in a URI, they are to be treated differently. (There’s been many security holes caused because people treat `%2F..%2F` the same as `/../` and it’s not.)

> 
> — millions of ways of interpreting whitespace or the lack thereof.  I’ve lost count.

Could you provide one or two examples please?

> 
> 
> I do not think any longer that anything that is meant to see significant usage can be designed without designing in extensibility points from the start.  At least if it is supposed to last.
> 
> Grüße, Carsten
> 
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json