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

[Dean Landolt <[e-mail]>]

On Fri, Jun 7, 2013 at 1:02 PM, Douglas Crockford <[e-mail]>wrote:

> On 6/7/2013 9:59 AM, Allen Wirfs-Brock wrote:
>
>> On Jun 7, 2013, at 9:46 AM, Douglas Crockford wrote:
>>
>>  On 6/6/2013 8:42 AM, Allen Wirfs-Brock wrote:
>>>
>>>> Given that duplicate names have historically been valid, that some
>>>> people use them, and that the standard ECMAScript JSON parser accepts them
>>>> I don't see why allowing a parser to reject duplicate names is helpful.
>>>>
>>>>
>>>>
>>>>  Because some parsers do so, and have for years. JSON.parse is not the
>>> only JSON parser. Our purpose here is not to attempt to fix this thing,
>>> because fixing it will break it. There were unfortunately ambiguities in
>>> the RFC. If we can, we should remove the ambiguities, but we must do so
>>> without changing the meaning of what JSON is.
>>>
>> I think it is more important to preserve the validity of existing
>> archival datasets then it is to preserve the validity of existing parsers
>> that throw on duplicate keys.
>>
>>  We should not be invalidating data or programs. We should only be
> explaining better. No breakage is acceptable. No breakage.



In this case "no breakage" effectively means no hope of interoperability
going forward. What, then, is the point of this exercise? To echo AWB's
point, I've seen the duplicate-keys-for-comments technique used (and
encouraged) by many in the js community for years -- I'm sure there's a
large volume of otherwise-valid json out there. This is handled in a
variety of ways in the wild -- shouldn't this be a high priority to
correct? And all things being equal, programs rot a lot faster than data --
there's no correcting for the mass of historical duplicate-key json.

Another possible solution: specify that parsers MUST NOT throw on duplicate
keys and recommend omitting duplicate keys entirely. Given history I
believe this is the only sane way to handle duplicate keys -- as was noted
earlier in this thread they're completely useless after a
parse/serialization cycle anyway. This may put some noses out of joint but
web reality suggests this is the only robust solution.