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

[Jacob Davies <[e-mail]>]

On Tue, May 20, 2014 at 1:50 PM, Paul Hoffman <[e-mail]> wrote:
> The goal of this document is to maximize interoperability. RFC 4627 and other specs had the rule that JSON texts had to be objects or arrays. Restricting JSON texts *in this profile* maximizes interoperability better than RFC 7159 did.

Restricting top-level elements to objects or objects and arrays
repeats the mistake of the original JSON specification. But almost
every JSON parser ignored that advice, most importantly including the
Javascript JSON.parse() method.

Unlike the other concerns being addressed, the issue of non-object
top-level elements is not a subtle gotcha. If an application says it
emits or receives JSON but fails to specify the numeric range they
support or fails to specify the behavior when duplicate keys are given
or fails to specify that non-character code points are disallowed,
there is a real risk of subtle interoperability problems. But if an
application says it emits or receives JSON strings as JSON documents,
the interoperability error with some client that does not support
top-level strings is gross. There is no chance of a subtle failure.

Mostly I think including this constraint is a mistake because it
overshadows the excellent advice given in the rest of the I-JSON spec
on the limits of numeric precision, non-character code points, and
duplicate keys. It makes I-JSON an unsuitable drop-in replacement for
JSON by making certain unambiguous and nearly-universally-supported
use cases illegal. This is throwing the baby out with the bathwater;
the rationale that it presents a real interoperability concern is not
really supportable, as the general indifference to dropping this
constraint in recent JSON specifications makes obvious.