Re: [Json] Differences between RFC 4627 or the current ECMAScript specification

[Tony Hansen <[e-mail]>]

On 9/27/2013 12:34 PM, R S wrote:
> On Fri, Sep 27, 2013 at 8:34 AM, Tony Hansen <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     RFC 4627 does not allow trailing commas in objects. Nor does
>     4627-bis. 
>
>
> RFC 4627 allows parsers to accept non-JSON if they wish, while
> ECMAScript does not allow this.

Your claim was that you had to change your parser of JSON to no longer
allow trailing commas because of converting to parsing ECMAScript. I
disagree with that assessment.

You had added your own non-standard extension to JSON (accepting
trailing commas) to your parser. Note that ECMA's restrictions on
parsers are only on implementations of ECMAScript. ECMA does NOT say
that *your* parser may not continue to accept trailing commas, except in
the specific case of your parser being used in an implementation of
ECMAScript's JSON.parse() function. That is, if your function is not
used in an implementation of JSON.parse(), ECMA places no restrictions
on it; it certainly is not restricted in the same ways that ECMAScript's
JSON.parse() is restricted. You chose to remove that non-standard
extension, but only because you chose to *follow* the same restrictions
as ECMAScript's JSON.parse().

Did the JSON spec say you could add your own extension to your parser?
Yes it did. However, if someone wrote JSON using a trailing comma,
they're going into non-interoperable territory.

ECMA also extends 4627-JSON by accepting additional top-level
primitives. ECMA's JSON.parse() is still a 4627-JSON-compliant parser
because it properly interprets 4627-JSON. However, someone writing JSON
using ECMA's extensions will only safely be interoperable with someone
using ECMAScript's JSON.parse() or another parser that's been similarly
extended. But they aren't interoperable with the many other JSON
libraries that haven't been similarly extended.

    Tony Hansen