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

Douglas Crockford <douglas@crockford.com> Fri, 07 June 2013 17:02 UTC

Return-Path: <douglas@crockford.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7722021F9385 for <json@ietfa.amsl.com>; Fri, 7 Jun 2013 10:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxIBKskwexGP for <json@ietfa.amsl.com>; Fri, 7 Jun 2013 10:02:40 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 652CC21F92E3 for <json@ietf.org>; Fri, 7 Jun 2013 10:02:39 -0700 (PDT)
Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lq9Xs-1U7WVi1quu-00do2j; Fri, 07 Jun 2013 13:02:33 -0400
Message-ID: <51B2121B.5080801@crockford.com>
Date: Fri, 07 Jun 2013 10:02:19 -0700
From: Douglas Crockford <douglas@crockford.com>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <D0A99569-0915-4862-A7AE-9DE51C2E90C0@yahoo.com> <51AFB3F8.8060708@crockford.com> <8F32953C-C788-4DC9-888E-920E2BEB7FDD@yahoo.com> <831B8E46-F239-4353-8F95-8DF3F9BD2E78@yahoo.com> <51AFC924.2030805@crockford.com> <DA7A83A2-1C1F-4E74-BF6A-DA943B07AB59@vpnc.org> <60141305-DCEA-4EC6-9CDF-82B52B13AE91@wirfs-brock.com> <51B20E48.8040109@crockford.com> <944ECA7F-A548-4903-9526-847065066E8E@wirfs-brock.com>
In-Reply-To: <944ECA7F-A548-4903-9526-847065066E8E@wirfs-brock.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V02:K0:srROkvQXWBkVt+PwjWr8hVt8lRO1mMdHTNmhcOAjIbU 2eLt9+DCWuKLIZrgNGGOhbCSXKKpXSn3ETwsWiAcg3JwiKI1LD GQqluNavIF9CWOZ4SiuN7z0OQejLcsSgl6YZniUz+aUFiWSP6G ifdH97oHEfPXSQdeMJ0w2RK++McocO0+m964gWwlAZL3VGXMtj P/AgsTYvFh1L9MAAiywjPi6j/PHKEAUSQYQxJSFhpZnaiCwATy v0vot52HYAUS0HP5hzb5gH3rtS4s0v7DORDXM77aZWhA5f5EU+ QmSuMcFgXX3uQNeJv3RgIXjv1uyTSbT7LgRMDn9ehiEouRnvjy Kq1lINLCaKJ4Q9rSwQ+3k6nAklKo6oJXQ2KNeZZ/j
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] The names within an object SHOULD be unique.
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jun 2013 17:03:01 -0000

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.