Re: [Json] I-JSON Tpic #2: Top-Level

["Manger, James" <[e-mail]>]

Only allowing objects and arrays at the top level was a cause of interop problems.
It was a bad feature, an unnecessary restriction, that we should not perpetuate. RFC7159 and ECMA-404 have taken a great leap to remove it so I don’t want I-JSON to try to resurrect it.

I would be happy to use a JSON function that: required UTF-8; failed on surrogates; failed on duplicates; ignored element order; failed on integers beyond 2^53; failed on floats with more than 22 digits; failed on invalid JSON (eg trailing commas, comments etc).
I would NOT be happy to use a JSON function that: failed when the top-level isn’t an object.
I want to be happy to use a JSON function if it says it supports I-JSON.

--
James Manger

From: Tim Bray [mailto:[e-mail]]
Sent: Wednesday, 30 April 2014 1:41 PM
To: Manger, James
Cc: IETF JSON WG
Subject: Re: [Json] I-JSON Tpic #2: Top-Level

I’m sorry, but the central idea of I-JSON is to explicitly rule out all the interoperability problems identified in RFC7159: How to produce maximally-interoperable JSON.  7159 specifically says that for interoperability a JSON Text should be an object or array, and the idea of making I-JSON less constraining totally defeats its purpose.  This is just not a reasonable direction to be going.

Yes, it’s perfectly clear to any language lawyer that in ECMAScript, 42 is a first-class JSON text, nobody is disputing this.

On Tue, Apr 29, 2014 at 8:19 PM, Manger, James <[e-mail]<mailto:[e-mail]>> wrote:
> Protocols with messages which are objects are better than other protocols, because they are architecturally friendly to MustIgnore policies.
Perhaps we should say a MustIgnore policy applies to all objects in I-JSON; instead of merely making a MustIgnore policy possible via a somewhat tangential rule that the top-level must be an object.

--
James Manger