Re: [Json] The names within an object SHOULD be unique.

[Stefan Drees <[e-mail]>]

On 2013-06-10 19:08 CEST, Stephen Dolan wrote:
> On Mon, Jun 10, 2013 at 6:01 PM, Paul Hoffman ... wrote:
>> <no hat>
>>
>> On Jun 10, 2013, at 9:55 AM, Stephen Dolan ... wrote:
>>
>>> The issue is, that currently there exists a JSON document which one
>>> RFC-conforming correct JSON parser can say is indistinguishable from
>>> {a: true}, and another equally RFC-conforming correct JSON parser can
>>> say is indistinguishable from {a: false}.
>>>
>>> While my example might not have been great, this still seems easily
>>> exploitable: two parsers parsing a supposedly standard format can be
>>> tricked into seeing completely different results from the same input.
>>> Surely it would be better if we could say that one of those parsers
>>> was not RFC-conforming?
>>
>> Stated that narrowly, yes. But given your first paragraph, the comparison might be
>> more fully stated as "would it be better if we could says that one of these parsers was
>> not RFC-conforming if making such a statement caused what was a stored valid
>> JSON text now non-valid".
>
> I don't propose making any stored valid JSON text become non-valid.
> {a: true, a: false} is currently a valid JSON text, and it should
> remain so or things would break.
>
> Some JSON parsers consider that document distinguishable from {a:
> false} (e.g. streaming parsers that return all key/value pairs). Most
> of them don't.
>
> I propose that it be invalid to consider that document
> indistinguishable from {a: true}. Parsers are free to accept or reject
> it, and if they accept it they are free to return either one or two
> "a" entries, but if they only return one it must be {a: false}. ...

I presume, that if round-tripping - that is taking the "JSONing" as 
reversible operation for whatever is deemed important to keep intact 
over multiple encode-decode cycles - would have been a concern, this 
somehow would have been noted in the JSON RFC right from the start ;-)

In the current discussions I see a lot of focus on the transformation 
from JSON text into some storage structure of another representation 
motivated by consequences thereof.

If I take eg. a conforming JSON parser that keeps even the duplicated 
entries inside a map in the parsers implementation "private 
representation" and than let it act - say as a proxy - and generate 
"matching" JSON text from that again, it is perfectly valid and ok to 
receive:

     {a: true, a: false}

parse this (i.e. store) and emit as (re-)generated JSON text (forward):

     {a: false, a: true}

Right :-?)


There is some traditional asymmetry of "interest" comparing:

A) Private Storage Representation of Generator

and

B) Private Storage Representation of Parser

Isn't it? It looks more like JSON text is "simply found" as the 
interchange of the JSON represented data is the emphasis not the initial 
transformation of whatever that lead to the JSON text in the first place.

So I think what generators MAY introduce as indeterminism into the 
conversion (since years), the parsers will have to deal with (wishes 
aside).
Setting all "hope" on this weak ordering assumption leading to the 
concept of a "last" entry, which breaks down in the proxy sample given 
above, might be misleading.

Please note, that I do believe, that the discussions transported through 
all these - I guess already - 300000 words exchanged back and forth in 
the endeavour to apply some cosmetics to the 2000 words RFC are of 
sufficient value for everyone participating :-)

Stefan.