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

Stephan Beal <sgbeal@googlemail.com> Wed, 05 June 2013 21:14 UTC

Return-Path: <sgbeal@googlemail.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 5EE6621E8083 for <json@ietfa.amsl.com>; Wed, 5 Jun 2013 14:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001]
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 Eb8KrjyvDZVy for <json@ietfa.amsl.com>; Wed, 5 Jun 2013 14:14:36 -0700 (PDT)
Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD1121E8087 for <json@ietf.org>; Wed, 5 Jun 2013 14:14:36 -0700 (PDT)
Received: by mail-ea0-f173.google.com with SMTP id g15so1450556eak.4 for <json@ietf.org>; Wed, 05 Jun 2013 14:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CdoPCTNneWqIsIyKDf7tsJkscRIGhaFdFkCn+NswueM=; b=ui79g8RigoeWzM+6oTKLFEpIsy8vNC8AjwpVb3HJQkp0tKuaawcTVTc2/lF6IoBdh/ 4EBpUtpHf6CwZL3qDaSSXYju9uSI3rCotC/3EWaSIE/PJvyda7R4roLYLv+xfxATiM0g wzikBGMiqj1UwVFf9KcOm86XLkWaGzb5CtW84y2DFq8WNuyk+9o1R3/0Z2fw1VFdMsYu S49LJ9IDhW6yr4w8A9E7Eh6oFlB+7Y+9lwwF2Wp4rFbHRDbu8fYlI1SQ8k4d83h/7xJt oVmlBkbl/KYIrgV4+E91ZYnsuwnJHu5ya152cFxKMvkI+h0DXGO5HLoIpd3hd6ABkUtW T5Pw==
MIME-Version: 1.0
X-Received: by 10.181.12.1 with SMTP id em1mr8556545wid.4.1370466873170; Wed, 05 Jun 2013 14:14:33 -0700 (PDT)
Received: by 10.194.42.230 with HTTP; Wed, 5 Jun 2013 14:14:33 -0700 (PDT)
In-Reply-To: <D0A99569-0915-4862-A7AE-9DE51C2E90C0@yahoo.com>
References: <51AF8479.5080002@crockford.com> <51AF9ACF.5020507@cisco.com> <D0A99569-0915-4862-A7AE-9DE51C2E90C0@yahoo.com>
Date: Wed, 05 Jun 2013 23:14:33 +0200
Message-ID: <CAKd4nAj2KPJRhY--mbbmV7ia-FQfKMA8KtwsZBBW2U5F3Hh8cA@mail.gmail.com>
From: Stephan Beal <sgbeal@googlemail.com>
To: "json@ietf.org" <json@ietf.org>
Content-Type: multipart/alternative; boundary="f46d043c7e3026e40404de6eafc1"
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: Wed, 05 Jun 2013 21:14:37 -0000

On Wed, Jun 5, 2013 at 10:59 PM, Vinny A <jsontest@yahoo.com> wrote:

> If parsers are accepting duplicate keys, they're already non-compliant.
> RFC 4627 states that keys should be unique, and the org.json reference
> parser throws an exception when it hits a duplicate key (line 1186 in
> JSONObject).
>

(Sorry, Vinny - gmail is giving me all kinds of grief with the list
replies.)

"should" is not "must" :/.


> If any implementation is relying on using duplicate keys, they should also
> understand that they are already violating best practice.
>

Absolutely.


> While I'd prefer to simply state that implementations MUST generate unique
> keys, Mr. Lear's suggestion gets my +1.
>

But that only solves the generator side of the equation, and that solution
would imply that the parser also MUST NOT parse them (because they "can't"
be generated, so why bother?), regardless of best/worse-practice. i.e. it
would force changes onto existing parsers if they want to be officially
compliant. Maybe i'm nit-picking, but that point could certainly disappoint
some people who would have to re-label their implementations as "JSON
comp^H^H^H^Halmost-compliant".