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

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

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

> It doesn't seem to fit with the current mission, which is not to extend
> JSON but to clarify the spec and add warnings about compatibility
> issues.

This issue fits the charter perfectly. It is a significant inconsistency in the JSON community.

  It is acknowledged that there are differences between RFC 4627 and the
  ECMAScript specification in the rules for parsing JSON. Any changes that
  break compatibility with existing implementations of either RFC 4627 or
  the ECMAScript specification will need to have very strong justification
  and broad support. All differences between RFC 4627 or the current
  ECMAScript specification will be documented in the new RFC.

The last sentence above says 4627-bis needs to document the text=obj/array vs text=any-value difference. The choice is to document it as a difference to ECMAScript or as a difference to 4627. However it is documented, I hope JSON library developers get the message not to bother enforcing the text=obj/array restriction; and JSON message designers notice that they don’t need to add an extra wrapping layer (a la SOAP) when they want to exchange arbitrary JSON values.


> There are a whole mess of common extensions I'd rather do before I do
> this.

Well this is the primary extension that is consistently supported by ECMAScript and many implementations so I suggest this should be a priority before a "whole mess of common extensions".

>  For one thing, JSON numbers aren't self-delimiting, though strings
> and true/false/null are.

So what? It is hard to imagine how numbers not being self-delimiting will break anything that wasn’t already dodgy.

--
James Manger