On 08 Dec 2013, at 00:05, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

> 
> On Dec 7, 2013, at 12:30 PM, Carsten Bormann wrote:
> 
>> On 07 Dec 2013, at 19:05, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> 
>>> Parsing must preserve this order, in both cases, because downstream semantics may be dependent upon the orderings.
>> 
>> That would be a major breaking change.  The JSON WG is chartered not to do those.
> 
> It is also a major breaking change if downstream semantics can't depend upon the ordering of object members.  

Wait a minute.  It can’t be a breaking change because it is not a change.

JSON parsers are free to implement extensions (section 4), so none of the JavaScript extensions make them non-conforming JSON parsers.
Many JSON parsers won’t implement these extensions, and many JSON generators won’t be able to generate them, so arguing they have become part of JSON because they are in one parser doesn’t quite work.

> When we prepared ECMA-404 we concluded that characterizing JSON objects as unordered was a mistake in the original RFC.  

Silently making this breaking change is a nice illustration for the process issues that might make some of us a bit reluctant to use ECMA-404 as a normative reference, even if it were turned into a technically superior spec.

> The original author did not object to this interpretation. 

It is, however, still on json.org, so we seem to have a bit of a communication problem here.

> JSON is derived from JavaSript

“Was originally derived” would be closer; after JavaScript changed, JSON is not even a subset of JavaScript any more.
And that historical ancestry doesn’t make JavaScript specifications the specification for JSON.

> (whose standard is ECMA-262) and since 2009, ECMA-262 (and its clone ISO/IEC-16262) has included a normative specification for parsing JSON text that includes an ordering semantics for object members.

As it is free to do; that doesn’t change JSON the data interchange format though.

Grüße, Carsten

On 08 Dec 2013, at 00:05, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

> 
> On Dec 7, 2013, at 12:30 PM, Carsten Bormann wrote:
> 
>> On 07 Dec 2013, at 19:05, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> 
>>> Parsing must preserve this order, in both cases, because downstream semantics may be dependent upon the orderings.
>> 
>> That would be a major breaking change.  The JSON WG is chartered not to do those.
> 
> It is also a major breaking change if downstream semantics can't depend upon the ordering of object members.  

Wait a minute.  It can’t be a breaking change because it is not a change.

JSON parsers are free to implement extensions (section 4), so none of the JavaScript extensions make them non-conforming JSON parsers.
Many JSON parsers won’t implement these extensions, and many JSON generators won’t be able to generate them, so arguing they have become part of JSON because they are in one parser doesn’t quite work.

> When we prepared ECMA-404 we concluded that characterizing JSON objects as unordered was a mistake in the original RFC.  

Silently making this breaking change is a nice illustration for the process issues that might make some of us a bit reluctant to use ECMA-404 as a normative reference, even if it were turned into a technically superior spec.

> The original author did not object to this interpretation. 

It is, however, still on json.org, so we seem to have a bit of a communication problem here.

> JSON is derived from JavaSript

“Was originally derived” would be closer; after JavaScript changed, JSON is not even a subset of JavaScript any more.
And that historical ancestry doesn’t make JavaScript specifications the specification for JSON.

> (whose standard is ECMA-262) and since 2009, ECMA-262 (and its clone ISO/IEC-16262) has included a normative specification for parsing JSON text that includes an ordering semantics for object members.

As it is free to do; that doesn’t change JSON the data interchange format though.