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

On 2019-05-10 09:56, Manger, James wrote:
>> “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.
> 
> NO WAY!
> RFC8259 JSON explicitly says when keys in an object are not unique the behaviour of parsers is unpredictable. So it you specify a system that gives meaning to repeated keys then lots of JSON parsers will be unusable in this case. Hence, it is harmful to call that JSON, call it "ECMA 404 syntax without normal JSON semantics".
> 
>> 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.
> 
> The number of elements in a JSON object and the number of headers in an HTTP message are both theoretically unbounded. But there is a strong assumption that the latter (#headers) is limited: typically 10s, perhaps 100, never 1000s. Web servers limit total header size to, say, 8KB. That is small enough to always handle repeats. While many JSON objects will also be small, JSON is such a generic format that you cannot make a global assumption that JSON objects will always be small enough to hold in memory. Hence some apps will need streaming JSON processors that cannot reasonably detect duplicate keys (so the "SHOULD" is there to accommodate these).
> 
> 
>> 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.
> 
> RFC8259 JSON does have that text. For example, "good interoperability can be achieved by implementations that expect no more precision or range than [64-bit floats] provide"; "when the names within an object are not unique, the behavior [...] is unpredictable".
> 
> For more concrete text, use RFC7493 I-JSON (Internet JSON is a restricted profile of JSON).

Right on!  I have "hammered" a bit on Oracle who interpreted I-JSON "literally" making small BigIntegers serialize as Number and big such as String which probably breaks most schemas.

They now seem to have come to their senses:
https://github.com/eclipse-ee4j/jsonp/issues/160

Oracle do not support duplicate keys either.  If you want to use such you are probably not really a candidate for using a schema.

JSON is slowly but surely getting better :)

thanx
Anders

> 
> --
> James Manger
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
> 