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

[Jacob Davies <[e-mail]>]

On Wed, May 21, 2014 at 11:44 AM, Joe Hildebrand (jhildebr)
<[e-mail]> wrote:
>>issue in starker terms: interop with RFC4627 implementations with no
>>option to parse all types at the top-level.
>
> That's what I want.

I have to ask again: why?

The other issues mentioned in I-JSON are subtle interoperability
problems that could trip people up unless they take care to use a
compliant parser/encoder. In fact, they certainly will trip people up
if they do not carefully choose a good library, which means not
picking any old RFC4267 library, because there are lots of extant
libraries that allow the precise constructs that I-JSON mentions.

For instance, there are multiple JSON libraries - including the Java
json.org library - that encode Java longs as JSON numbers, which is
exactly the kind of problem I-JSON is concerned with, since Javascript
cannot correctly deserialize these values, a problem that has led to
numerous prominent bugs whose fix (replacing numbers with strings) was
not backwards-compatible. The point about subtle problems is that they
can go unnoticed for a long time and the cost of fixing them is large.

These kinds of problems are what I-JSON intends to address, but to use
I-JSON effectively means either:

1. Using an pre-existing JSON library that is already pretty-well
compatible with the I-JSON requirements (for instance, Javascript's
JSON.parse()). This does NOT include many - perhaps even most -
existing JSON libraries. In my experience with the Java libraries,
most of them fail on at least one of number range, duplicate keys, and
non-characters. Yet almost all of them handle top-level values of any
type just fine (I believe the json.org code does not).

or 2. Writing new libraries that are fully compliant with I-JSON, in
which case the point about existing libraries is irrelevant.

I have never heard of any interoperability problems caused by
top-level values of non-object types and I find it hard to imagine it
would be a real concern, since agreement on the types to be sent and
received is hard to avoid upfront and grossly obvious when it occurs.
In the cases where a top-level primitive or array is desirable, it
will be pretty clear why that is the case (most importantly, selecting
part of a composite object).

This restriction was widely ignored since it never existed in
Javascript in the first place; eval() and JSON.parse() have always
accepted all Javascript literal values anyway. Most people just did
what JS did and accepted them too. That there exist some libraries
that enforce it is not actually evidence that it matters to I-JSON,
since most of those libraries probably fail the other I-JSON tests and
will need rewriting to comply with its requirements.

The restriction to objects and arrays at the top level was a clever
hack to avoid using any out-of-band information to distinguish between
UTF variants at a time when UTF-8 had not taken over the world. It was
obsolete a long time ago. Replicating it in recommended guidance for
using JSON in modern applications just seems very odd to me (and the
original rationale for distinguishing UTF variant doesn't even exist
in I-JSON since UTF-8 is required).