Re: [Json] I-JSON vs. JSON-S

[Nico Williams <[e-mail]>]

On Mon, Jul 8, 2013 at 10:25 AM, Bjoern Hoehrmann <[e-mail]> wrote:
> http://www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/ proposes that the
> XMLHttpRequest implementations parse JSON HTTP responses by way of
>
>   JSON.parse(decode_utf8_with_bom_and_error_recovery(bytes))
>
> That extends and subsets what is defined in RFC 4627. If this is imple-
> mented as proposed, and my parser does something else, I may eventually
> have to deal with bug reports telling me "but it works with XHR". And I
> might have to adapt my parser. Same for many other implementations.

Every parser (and generator) I've seen takes options arguments.

For all our debates over this I think we'll probably just end up with
most implementations supporting both JSON forms.

> http://www.w3.org/TR/2012/WD-xslt-30-20120710/#func-parse-json proposes
> a `parse-json` function that takes option parameters like "RFC4627" and
> "ECMA-262" to select among JSON profiles. People seeing this might ask
> that my parser also has such options.

No doubt they will.

> We could take RFC4627-JSON, remove unpaired surrogate escapes and dupli-
> cate keys and call it RFC7xxx-JSON, but that would make ECMA-JSON and
> RFC-JSON more different. RFC4627-JSON with all values at the top level
> allowed would make them more similar. It would improve our understanding
> of what is JSON.

I agree that allowing any types at the top-level seems like a
no-brainer, but others disagree vehemently, and I don't think I care
that much about that.

Nico
--