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

[Tony Hansen <[e-mail]>]

Thank you Rob, I appreciate that additional bit of information. In that
case, you were indeed required to remove your private extension in order
to be compliant with the ECMAScript specification. My point remains
though: this was a case of removing a private extension you had
previously allowed in your parser; it was not something that was done
because the JSON language itself was different.

This may seem like it's splitting hairs to you, but knowing where we're
both coming from is important so that we understand each other better.

    Tony Hansen

On 10/1/2013 12:38 AM, R S wrote:
> my implementation was used for ECMAScript JSON.parse.
>
> - Rob
>
> On Saturday, September 28, 2013, Tony Hansen wrote:
>
>     On 9/27/2013 12:34 PM, R S wrote:
>>     On Fri, Sep 27, 2013 at 8:34 AM, Tony Hansen <[e-mail]
>>     <javascript:_e({}, 'cvml', '[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
>
>
>
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json