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.

If the purpose of removing semantics from the specification is to create a derivative of JSON where this matters, I can finally have my binary data in JSON.  You see, I have proposed for a while that any string that is immediately preceded by two newlines is interpreted as a base64url representation of a binary string instead of a text string.  Problem solved.

If this usage of whitespace seems somehow revolting, maybe you get an idea of how unacceptable reducing the definition of JSON to its syntax is.  Interoperability requires more than common syntax.

In JSON, objects are unordered collections or sets of name/value pairs.  It says so right there on json.org (“sets”), and it says so in RFC 4627 (“collections”)*).  We may not like it, but it has been a promise for a decade.  We need to heed it.  (Another promise was that JSON doesn’t change**).)

Data interchange formats where this is not the case may be using the JSON syntax, but aren’t JSON.

Grüße, Carsten

*) (The difference is unfortunate, but a fact that we need to deal with.)

**) Which can’t be strictly true, as JSON is as much defined by the collection of its implementations as by its specification.  But that’s just limiting the extent of the promise, not giving us a free get out of jail card.

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.

If the purpose of removing semantics from the specification is to create a derivative of JSON where this matters, I can finally have my binary data in JSON.  You see, I have proposed for a while that any string that is immediately preceded by two newlines is interpreted as a base64url representation of a binary string instead of a text string.  Problem solved.

If this usage of whitespace seems somehow revolting, maybe you get an idea of how unacceptable reducing the definition of JSON to its syntax is.  Interoperability requires more than common syntax.

In JSON, objects are unordered collections or sets of name/value pairs.  It says so right there on json.org (“sets”), and it says so in RFC 4627 (“collections”)\*).  We may not like it, but it has been a promise for a decade.  We need to heed it.  (Another promise was that JSON doesn’t change\*\*).)

Data interchange formats where this is not the case may be using the JSON syntax, but aren’t JSON.

*) (The difference is unfortunate, but a fact that we need to deal with.)

**) Which can’t be strictly true, as JSON is as much defined by the collection of its implementations as by its specification.  But that’s just limiting the extent of the promise, not giving us a free get out of jail card.

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.

If the purpose of removing semantics from the specification is to create a derivative of JSON where this matters, I can finally have my binary data in JSON.  You see, I have proposed for a while that any string that is immediately preceded by two newlines is interpreted as a base64url representation of a binary string instead of a text string.  Problem solved.

If this usage of whitespace seems somehow revolting, maybe you get an idea of how unacceptable reducing the definition of JSON to its syntax is.  Interoperability requires more than common syntax.

In JSON, objects are unordered collections or sets of name/value pairs.  It says so right there on json.org (“sets”), and it says so in RFC 4627 (“collections”)\*).  We may not like it, but it has been a promise for a decade.  We need to heed it.  (Another promise was that JSON doesn’t change\*\*).)

Data interchange formats where this is not the case may be using the JSON syntax, but aren’t JSON.

Grüße, Carsten

*) (The difference is unfortunate, but a fact that we need to deal with.)

**) Which can’t be strictly true, as JSON is as much defined by the collection of its implementations as by its specification.  But that’s just limiting the extent of the promise, not giving us a free get out of jail card.