domenic at domenicdenicola.com (2013-12-10T00:58:20.482Z)
On Dec 7, 2013, at 11:00 PM, Martin J. Dürst wrote:
> On 2013/12/08 9:49, John Cowan wrote:
>> Tim Bray scripsit:
>>
>>> I assume all parties to the discussion know that in 100% of all
>>> programming-language libraries in use for dealing with JSON as
>>> transmitted on the wire, JSON objects are loaded into hash tables
>>> or dicts or whatever your language idiom is, and there is no way
>>> for software using those libraries to discover what order they were
>>> serialized in,
>>
>> Well, no, not 100%. In Lisp-family languages, JSON objects are often
>> deserialized to ordered constructs. Nevertheless:
>
> Similarly, as of somewhere around version 1.9.x or 2.0, Hash entries in Ruby are ordered, and one would assume that the original order in JSON would be reflected in the order of the Hash entries.
>
>>> any suggestion that this order should be considered significant for
>>> application usage would be regarded as insane.
>>
>> +1 to that.
>
> +1 here, too.
Millions of web developers write code with these sorts of dependencies. Not because they are insane, more often it is because then are unaware of the bit falls. However, its not an interoperability issue if they are writing web application code that is only intended run in a web browser and all browsers behave the same on that code.
More broadly, the JSON language binding parsers that I'm most familiar with do not generate a high fidelity view of all valid JSON texts that they are presented with. It would be a mistake to depend upon such parsers to interchange data using JSON schemas that assign meaning to the ordering of object members. However, that would not necessarily be the case for an application that is using a streaming JSON parser.
Consider this informal description of a data schema that is representable using JSON.
Conversation Schema: A Conversation is a JSON text consisting of a single JSON object. The object may have an arbitrary number of members. The members represent a natural language conversation where the key part of each member identifies participant in the conversation and the value part of each member is a JSON string value that captures a statement by the associated participant. Multiple members may have the same key value, corresponding to multiple statements by the same participant. The order of the members corresponding to the order in which the statements were made during the conversation.
And here is an example of such a JSON text:
```json
{
"allenwb": "there is an objectively observable order to the members of a JSON object",
"JSON WG participant 1": "It would be insane to depend upon that ordering",
"allenwb": "not if there is agreement between a producer and consumer on the meaning of the ordering",
"JSON WG participant 2": "But JSON.parse and similar language bindings don't preserve order",
"allenwb": "A streaming JSON parser would naturally preserve member order",
"JSON WG participant 2": "I din't think there are any such parsers",
"allenwb": "But someone might decide to create one, and if they do it will expose object members, in order",
"allenwb": "Plus, in this particular case the schema is so simple the application developer might well design to write a custom, schema specific streaming parser."
}
```
On Dec 7, 2013, at 11:00 PM, Martin J. Dürst wrote: > On 2013/12/08 9:49, John Cowan wrote: >> Tim Bray scripsit: >> >>> I assume all parties to the discussion know that in 100% of all >>> programming-language libraries in use for dealing with JSON as >>> transmitted on the wire, JSON objects are loaded into hash tables >>> or dicts or whatever your language idiom is, and there is no way >>> for software using those libraries to discover what order they were >>> serialized in, >> >> Well, no, not 100%. In Lisp-family languages, JSON objects are often >> deserialized to ordered constructs. Nevertheless: > > Similarly, as of somewhere around version 1.9.x or 2.0, Hash entries in Ruby are ordered, and one would assume that the original order in JSON would be reflected in the order of the Hash entries. > >>> any suggestion that this order should be considered significant for >>> application usage would be regarded as insane. >> >> +1 to that. > > +1 here, too. Millions of web developers write code with these sorts of dependencies. Not because they are insane, more often it is because then are unaware of the bit falls. However, its not an interoperability issue if they are writing web application code that is only intended run in a web browser and all browsers behave the same on that code. More broadly, the JSON language binding parsers that I'm most familiar with do not generate a high fidelity view of all valid JSON texts that they are presented with. It would be a mistake to depend upon such parsers to interchange data using JSON schemas that assign meaning to the ordering of object members. However, that would not necessarily be the case for an application that is using a streaming JSON parser. Consider this informal description of a data schema that is representable using JSON. Conversation Schema: A Conversation is a JSON text consisting of a single JSON object. The object may have an arbitrary number of members. The members represent a natural language conversation where the key part of each member identifies participant in the conversation and the value part of each member is a JSON string value that captures a statement by the associated participant. Multiple members may have the same key value, corresponding to multiple statements by the same participant. The order of the members corresponding to the order in which the statements were made during the conversation. And here is an example of such a JSON text: ------------start JSON text------------- { "allenwb": "there is an objectively observable order to the members of a JSON object", "JSON WG participant 1": "It would be insane to depend upon that ordering", "allenwb": "not if there is agreement between a producer and consumer on the meaning of the ordering", "JSON WG participant 2": "But JSON.parse and similar language bindings don't preserve order", "allenwb": "A streaming JSON parser would naturally preserve member order", "JSON WG participant 2": "I din't think there are any such parsers", "allenwb": "But someone might decide to create one, and if they do it will expose object members, in order", "allenwb": "Plus, in this particular case the schema is so simple the application developer might well design to write a custom, schema specific streaming parser." } -----------end JSON text------- Allen