On 12 Dec 2013, at 03:01, Allen Wirfs-Brock <[email protected]> wrote:
> And I'm pretty sure that you don't want to prevent a streaming parser from > presenting object members in the order in which they appear in the jSON text. Of course not. I’d recommend adding all the whitespace and a bit for each character indicating whether it was escaped or not (don’t laugh, there are JSON extensions that use this information). I think what many people here are saying is a point about interoperability, not about what a specific system “can” do. If you want to benefit from the wide availability of JSON implementations, you *cannot* make the object member order (or whitespace or escaping) significant in your application. The other side may not have a way to generate a specific member order (or form of whitespace or pattern of escaping). Of course, consenting applications can *extend* JSON to make all these things significant (and an implementation way want to be prepared for these extensions by, say, preserving character escaping information). However, saying that these applications are “using JSON” to communicate is inaccurate. They are using a JSON extension. It may not as obviously be an extension as, say, YAML is (it is still using the same grammar), but the fact that some aspects of the serial representation have been assigned a meaning that don’t have one in JSON still makes them using an extension. The fact that a widely used set of JSON implementations allows easy access to a JSON extension does not make that particular extension part of JSON any more than the convention of escaping the first character in a string to make it meta is a part of JSON. (Within a monoculture, it is always tempting to consider the features of that monoculture to be universal. Don’t yield to that.) Documenting the syntax of JSON without the attendant semantics is an exercise in leading developers on a path where they suddenly think they have to preserve all the fluff in the syntax just in case a JSON extension might use it. That’s not what JSON is about; JSON is about enabling parsers to aggressively eliminate the fluff, and enabling encoders to generate the fluff in a way that is convenient to them on their specific platform. Grüße, Carsten _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
