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

[Austin Wright <[e-mail]>]

> On May 8, 2019, at 23:50, Carsten Bormann <[e-mail]> wrote:
> 
> 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.

Well, JSON says that any number that fits the syntax is legal, and it doesn’t proscribe a way to normalize the numbers. And some software does keep track of significant figures. Why should those applications interpret JSON any differently?

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

“SHOULD" allows implementations to vary from the suggested behavior if there’s a reason. RFC8259 specifically says the reason is interoperability, and also says implementations might report all of the key-value pairs, even repeated keys. So if two implementations agree that repeated keys are meaningful, that seems legal to me.

I don’t see how the fact JSON can be streamed changes this. HTTP says servers must produce errors on some headers if they’re repeated; and HTTP is also parsed by streaming parsers.

Now, if the vast majority of JSON implementations don’t recognize excess precision, and don’t allow (or ignore) repeated keys, then maybe JSON should be updated to reflect that. Look at HTTP as an example, which is far more specific about how to handle these cases (e.g. repeated Host header, repeated Content-Length, media type q-values).

Cheers,

Austin.