On Jun 6, 2013, at 4:34 AM, Anne van Kesteren wrote:
> On Thu, Jun 6, 2013 at 12:29 PM, Douglas Crockford
> <[email protected]> wrote:
>> The JSON RFC says
>>
>> The names within an object SHOULD be unique.
>>
>> Sadly, there are people in the JavaScript community who interpreted SHOULD
>> to mean DON'T HAVE TO. In a perfect world, we would change the SHOULD to
>> MUST, but we can't. Interoperability and security concerns demand that we
>> specify what happens when keys are duplicated. So we may end up with
>> something like this:
>>
>> The names within an object SHOULD be unique. If a key is duplicated,
>> a parser SHOULD reject. If it does not reject, it MUST take only the
>> last of the duplicated key pairs.
>>
>> Does anyone see a problem with this?
>
> SHOULD reject seems too strong given that we know perfectly well we
> cannot do that. MAY seems much more reasonable or maybe MUST either
> reject or take the last of the duplicated key pairs (decision up to
> the parser API specification).
Some that should be pointed out is that one reason JSON needs to accept
duplicate field names is that some people currently use them to add comments
to JSON datasets:
{
"//": "This is a comment about my data",
"//": "that takes more than one line",
"field1" : 1,
"field2" : 2
}
The above is valid according to the existing RFC and is accepted as valid JSON
by the existing ES JSON.parse spec. We don't want to invalid existing JSON
datasets that use this technique so duplicate keys MUST be accepted.
What I would say, as a replacement for the current text 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.
I would be willing to loose the first sentence (containing the SHOULD) entirely
as it doesn't add any real normative value.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
