Re: [Json] section 1 paragraph 2 on what JSON can represent

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

> In 4627-JSON, Section 2 says that JSON-text is an object / array.
> In ECMA-JSON, Section 15.2 says that JSONtext is an object / array /
> string / number / boolean-literal / null-literal.
> ...
> Since we've as a WG rejected extending 4627-JSON to be compatible with
> ECMA-JSON,


Did we reject that? Lets un-reject it then.

There was a substantial discussion <http://www.ietf.org/mail-archive/web/json/current/msg00553.html>; half-a-dozen people strongly supported extending 4627-JSON to be compatible with ECMA-JSON; about 3 were strongly against; and a handful seemed to be in the middle.

There is clearly no major problem with allowing any JSON value at the top level as ECMAScript allows this and many implementations support it. It doesn't break backwards-compatibility as all existing texts are still valid. Objects and arrays are still self-delimiting if any systems rely on that implied property; and separating items with a space (or newline) trivially allows any JSON values to be self-delimiting. Auto-detecting charsets can still work. Detecting truncation (but not other varieties of modification) seems like a very marginal benefit, and would still apply to everything except numbers which are unlikely to be truncated as they are invariably short (eg 10s of bytes): noticing truncation of long items (objects, arrays, strings) is unchanged.

A note in 4627bis could still say you get more interoperability when sticking to objects and arrays at the top level.

A note in a subsequent JSON-best-practises doc could recommend using objects for messages in general, as they easily allows ignorable extensions via new elements.

--
James Manger