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

[Carsten Bormann <[e-mail]>]

On May 9, 2019, at 00:49, Austin Wright <[e-mail]> wrote:
> 
>> 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”?

Those people who want 3 and 3.0 to mean different things in a JSON document.

> 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`.

The language that Section 6 of RFC 8259 has inherited is not very good.
I cannot achieve a reading, though, that would support the above.

>> — 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,

Please re-read RFC 2119.  SHOULD is a normative statement.  It is not a MUST mainly because streaming implementations would have a hard time properly implementing that prohibition, so they are allowed to occasionally malfunction.  But a malfunction it is.

> 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.)

Well, yeah.  There is a reason we needed to maintain an IETF specification here.

>> - 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.)

I was talking about JSON, not about URIs, where percent notation indeed has different semantics (essentially creating a double of the encoded character without its syntactic properties).

The myths and misunderstandings cited in this message are actually a good corollary to the discussion of the Postel principle and soupification that is happening over at [e-mail]…  The JSON WG historically has shied away from making some of its statements very clear, and the resultant weasel wording will come back forever biting us.  I hope we can be better in the future.

Grüße, Carsten