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

[Allen Wirfs-Brock <[e-mail]>]

On Jun 7, 2013, at 10:43 AM, Vinny A wrote:

> 
> 
> On Jun 6, 2013, at 12:45 PM, Allen Wirfs-Brock <[e-mail]> wrote:
>> Allen Wirfs-Brock
>> ECMAScript Language Spec. Project Editor
> 
>> What I would say, as a replacement for the current text  <section 2.2> is:
>> 
>>         The names within an object SHOULD be unique.  If a key is duplicated, a parser MUST take  <<use?? interpret??>> only the last of the duplicated key pairs.
> 
> Just to be clear here, ECMA is OK with using MUST in regards to the last key pair?  

The ECMAScript standard specifies that the JSON parse built-in to a conforming ECMAScript implementation must accept duplicate key pairs and that it provides as its output the value of the last such pair.  Changing that behavior would be a breaking change that  we are very unlikely to make.

In general, the ECMAScript specification is hyper prescriptive about many behaviors, such as this, that traditionally would have been considered reasonable areas to allow implementation variability. The reason is that we really are a community of multiple independently developed implementations whose users (web developers) expect and demand identical behavior from our implementations. Experience has shown that when implementation variation is permitted that a de facto standard rapidly emerges around whatever implementation choices were made by the currently dominant implementation (historically MS Internet Explore on the desktop, more recently Webkit on mobile devices) and that all other implementations are forced to conform in order to remain viable. The preference within TC39 is to pro actively avoid such situations and reach early consensus on a single required behavior.

> 
> Because we already have proposed language that says that, but one of the points under contention on this list is what to do with duplicated key pairs.
> 
> Is the following language acceptable to ECMA (disclaimer: original text by Paul,  modifications by me):
> 
> 
> On Jun 6, 2013, at 10:24 AM, Paul Hoffman <[e-mail]> wrote:
>> The new text should use language that is already in RFC 4627; "key" is not such a word. To be fair to implementers, the new document also needs to deal with both emitters and parsers.
>> 
>> Proposal:
>> 
>> In Section 2.2:
>> Current:
>>   The names within an object SHOULD be unique.
>> Proposed:
>>   If the names within an object are not unique, the result of parsing the 
>>   object is unpredictable, and the parse may even fail completely. Thus,
>>   the names within an object SHOULD be unique.

First, a terminology issue. Section 2 is defining a grammar.  There are no syntactic ambiguities associated with multiple key-value pairs.  There is no reason they should cause parsing (take literally) to fail. The issue is what semantic interpretation is applied to such occurrences. JSON actually specifies very little with regard to the semantics of a JSON text but a plausible interpretation of duplicate key-value pairs might be that the entire JSON text is invalid because it is semantically ambiguous.  Personally I wouldn't call that a parsing issue.

Back to your question, Ecma TC39 is a consensus driven organization, and I don't think we would find consensus on the above proposed language.  More below

>> 
>> In Section 4, add a new paragraph:
>>   If a parser encounters an object with duplicate names, the parser MAY
>>   fail to parse the JSON text; if the parser accepts objects with duplicate
>>   names, it SHOULD accept only the last name/value pair that has the
>>   duplicate name. 
> 
> If we have to recommend to both parsers and emitters, I'd like to make a slight change to your wording:
> 
> In Section 2.2:
> Current:
>     The names within an object SHOULD be unique.
> Proposed:
>    The names within an object SHOULD be unique. Non-unique names have unpredictable effects (refer to sections 4 & 5).

This is better and I think we could get consensus (it's a variation of what I suggested above):

In Section 2.2:
Current:
    The names within an object SHOULD be unique.
Proposed:
   The names within an object SHOULD be unique because it is ambiguous as to which value should be associated with a duplicated key.

> 
> In Section 4 (Parsers) add a new paragraph:
>   If a parser encounters an object with duplicate names, the parser MAY fail to parse the JSON text; if the parser accepts objects with duplicate names, it MUST accept only the last name/value pair that has the duplicate name. 

I think this is too restrictive and gives license to reject existing valid datasets that use commenting conventions that introduce duplicate names.

Proposal:
   A parser MUST accept a JSON text that includes objects with duplicate names. A parser SHOULD associate with such a name the value of the last name/value pair that has the    duplicate name. 

TC39 would leave the specification of the ECMAScript JSON.parse function unchanged as it conforms to this proposal.

Note that a streaming parser might reasonably and validly present all of the duplicate name/value pairs to its clients.

> 
> In Section 5 (Generators) add a new paragraph:
>    A JSON generator SHOULD not duplicate names. If duplicate names are generated, the authoritative name/value pair MUST be listed last.

I think this is unnecessary if we specify that JSON text's with duplicated names must be accepted by parsers.

Allen