On Dec 7, 2013, at 12:30 PM, Carsten Bormann wrote: > On 07 Dec 2013, at 19:05, Allen Wirfs-Brock <[email protected]> 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. In particular, it means that the standard built-in ECMAScript JSON parsers as well as the classic JavaScript eval-based processing will be non-conforming. The latter is particularly puzzling as that was the original basis upon which JSON was defined. In fact, the only place that either the current RFC-4627bis draft or the original RFC-4627 says anything about object name/value pairs being "unordered" is the their introductions The 4627bis language appears to have been directly copied from the original RFC. i It isn't clear whether or not the introduction to 4627bis is intended to be normative. If it is, then I note that it also says in both the new and old documents) that JSON's design goals were for it to be "a subset of JavaScript". The syntactic elements of JavaScript that correspond to the JSON object syntax do have a specified ordering semantics. When we prepared ECMA-404 we concluded that characterizing JSON objects as unordered was a mistake in the original RFC. The original author did not object to this interpretation. > > If the purpose of removing semantics from the specification is to create a > derivative of JSON where this matters, No the purpose is to ensure that the specification remains compatible with the most widely deployed JSON parsers. Specifically, the ECMA-262 conforming parsers that are implemented by JavaScript engines in all major browsers. > 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**).) You also need to look at objective reality and consider the possibility that the informal (and non-normative text) on both the json.org website and in the original RFC never actually matched reality. JSON is derived from JavaSript (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. > > Data interchange formats where this is not the case may be using the JSON > syntax, but aren’t JSON. I disagree with this conclusion, but I think you are approaching an important point of possible agreement. The JSON syntax is used in many ways and for many purposes and if worthy of independent standardization. That is what ECMA-404 does. The JSON WG is certainly free (actually encouraged) to issue a normative standard that addresses interchange requirements for the MIME type application/json. But that should be view only as a spec. for application/json interchange, not the one and only JSON specification. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
