JSON Duplicate Keys
allen at wirfs-brock.com
Thu Jun 6 08:13:03 PDT 2013
On Jun 6, 2013, at 4:34 AM, Anne van Kesteren wrote:
> On Thu, Jun 6, 2013 at 12:29 PM, Douglas Crockford
> <douglas at crockford.com> wrote:
>> The JSON RFC says
>> The names within an object SHOULD be unique.
>> 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.
More information about the es-discuss