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

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Jul 2013 14:17:10 +0200

We'll have to bite the bullet at some point and acknowledge there
there are two levels of interoperability in the JSON ecosystem: I-JSON
and JSON-S.

I-JSON is the syntax adapted from JavaScript plus the data model.
Maps are maps, and strings are (Unicode character) strings.  I-JSON is
highly interoperable between different JSON implementations.  (I-JSON
stands for "interoperable JSON" or Tim Bray's "Internet JSON".)

JSON-S is just the syntax.  The data model being used may be related
to that of JSON, but ultimately is application specific.  So, Solr can
have their repeated keys, the "array of general 16-bit values"
faction can have their unpaired surrogates, etc.

When people talk about "not breaking things", it is just not clear
whether they mean "carry along all usages of JSON-S" or "make sure all
I-JSON implementations stil interoperate flawlessly".  That's why the
current charter may have less of a defined meaning than it appears.
Unless the two levels of interoperability are clearly identified, it
is not possible to break neither.

Grüße, Carsten

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 08 Jul 2013 17:25:25 +0200

>is not possible to break neither.

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.

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.

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.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Nico Williams <[email-masked]>
Date: Mon, 8 Jul 2013 11:35:01 -0500

> faction can have their unpaired surrogates, etc.

I think even for JSON-S we should leave the duplicate name text that's
in RFC4627.  Solr can still have their dup names, and strings would be
arrays of 16-bit code units.

> current charter may have less of a defined meaning than it appears.

I think "don't break me" mostly means: allow my non-I-JSON usage.
I-JSON is about guaranteeing interop because we [will] have a standard
with sufficiently normative language.  So, mostly agreed.

> is not possible to break neither.

Interop will require specifying which JSON you're using, or actually
sticking to a subset of JSON that happens to interop (which will be
very close to I-JSON, if not exactly I-JSON).  Seems fine to me, given
that we have no other way forward.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 8 Jul 2013 11:38:36 -0500

> 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.

> that my parser also has such options.

No doubt they will.

> allowed would make them more similar. It would improve our understanding

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
--