* Allen Wirfs-Brock wrote:
>On Dec 7, 2013, at 3:55 AM, Nico Williams wrote:
>> However, if a schema is also to be allowed to treat them as distinct
>> then the *meta-schema* must treat them as distinct.  I.e., no matter
>> what generic programming language bindings of JSON one users, the above
>> two JSON texts must produce equivalent results when parsed!
>
>"Equivalent" according to what definition?

I suspect intended was "must not produce".

>And I do care about the semantic issues.  They just don't belong in a 
>syntactic level specification of the JSON format such as ECMA-404. A 
>problem I see with the RFC4627bis is that it conflates a syntactic level 
>specification with a just little bit of semantic data model. It is 
>neither a pure syntactic specification nor a complete data model.

  JSON_texts = {     x | x is a JSON text }

  JSON_diffs = { (a,b) | a and b are elements of JSON_texts and
                         a is significantly different from b }

A pure specification in your sense above defines only membership in the
`JSON_texts` set. ECMA-404 is not pure in this sense because it defines
that e.g. `("[]", "[ ]")` is not a member of `JSON_diffs`. 

ECMA-404 does not define that

  ('{"x":1,"y":2}', '{"y":2,"x":1}')

is not a member of `JSON_diffs`. Right? It says the white space in the
example is insignificant, but it does not say order of key-value-pairs
in objects is insignificant. Carsten Bormann gave other examples like
ECMA-404's definition of equivalent escape sequences.

Readers of ECMA-404 might assume that it gives a complete description
of what people developing and operating JSON-based systems agree are
significant differences. They might build systems that rely on the order
of key-value-pairs in objects because of this, for instance

  http://wiki.apache.org/solr/UpdateJSON#Solr_3.1_Example

Systems like ecmascript's `JSON.stringify` API cannot ordinarily create
such JSON texts and would be unable to interact with such a system. That
is something the IETF JSON Working Group wishes to avoid, accordingly
they provide a more complete definition of the `JSON_diffs` equivalence
relation that better reflects rough consensus and running code of the
JSON community.

I believe the combination of impurity and incompleteness in ECMA-404 is
harmful to the JSON community.
-- 
Björn Höhrmann · mailto:bjoern at hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Allen Wirfs-Brock wrote:
>On Dec 7, 2013, at 3:55 AM, Nico Williams wrote:
>> However, if a schema is also to be allowed to treat them as distinct
>> then the *meta-schema* must treat them as distinct.  I.e., no matter
>> what generic programming language bindings of JSON one users, the above
>> two JSON texts must produce equivalent results when parsed!
>
>"Equivalent" according to what definition?

I suspect intended was "must not produce".

>And I do care about the semantic issues.  They just don't belong in a 
>syntactic level specification of the JSON format such as ECMA-404. A 
>problem I see with the RFC4627bis is that it conflates a syntactic level 
>specification with a just little bit of semantic data model. It is 
>neither a pure syntactic specification nor a complete data model.

    JSON_texts = {     x | x is a JSON text }

    JSON_diffs = { (a,b) | a and b are elements of JSON_texts and
                           a is significantly different from b }

A pure specification in your sense above defines only membership in the
`JSON_texts` set. ECMA-404 is not pure in this sense because it defines
that e.g. `("[]", "[ ]")` is not a member of `JSON_diffs`. 

ECMA-404 does not define that

    ('{"x":1,"y":2}', '{"y":2,"x":1}')

is not a member of `JSON_diffs`. Right? It says the white space in the
example is insignificant, but it does not say order of key-value-pairs
in objects is insignificant. Carsten Bormann gave other examples like
ECMA-404's definition of equivalent escape sequences.

Readers of ECMA-404 might assume that it gives a complete description
of what people developing and operating JSON-based systems agree are
significant differences. They might build systems that rely on the order
of key-value-pairs in objects because of this, for instance http://wiki.apache.org/solr/UpdateJSON#Solr_3.1_Example

Systems like ecmascript's `JSON.stringify` API cannot ordinarily create
such JSON texts and would be unable to interact with such a system. That
is something the IETF JSON Working Group wishes to avoid, accordingly
they provide a more complete definition of the `JSON_diffs` equivalence
relation that better reflects rough consensus and running code of the
JSON community.

I believe the combination of impurity and incompleteness in ECMA-404 is
harmful to the JSON community.