Re: [Json] Proposed minimal change for duplicate names in objects

"Jim Schaad" <> Sun, 07 July 2013 05:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 960E421F9AAC for <>; Sat, 6 Jul 2013 22:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Iwca7vD5VZ1L for <>; Sat, 6 Jul 2013 22:45:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B815621F9A23 for <>; Sat, 6 Jul 2013 22:45:09 -0700 (PDT)
Received: from Philemon ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 112A438EF1; Sat, 6 Jul 2013 22:45:07 -0700 (PDT)
From: "Jim Schaad" <>
To: "'Nico Williams'" <>, <>
References: <> <> <> <> <> <00cd01ce7a9f$19adeaa0$4d09bfe0$> <00d701ce7aa6$cc5fe700$651fb500$> <>
In-Reply-To: <>
Date: Sat, 6 Jul 2013 22:44:08 -0700
Message-ID: <00e401ce7ad5$00991c20$01cb5460$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJvUTXGqIW3iuu0l9rzv3fxldJ4PQL8G24kAqTixrQBjIQJ6gH4Oee+ATLeuAYCdtMjrQKGcuyml5xXbxA=
Content-Language: en-us
Subject: Re: [Json] Proposed minimal change for duplicate names in objects
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 Jul 2013 05:45:15 -0000

To be perfectly honest,  I would personally argue that this is a requirement that parsers need to enforce.  The JOSE group is going to need some interesting text about what happens if it is using a parser that does not enforce this mechanism.  And an even more interesting question of how this would ever be determined if the parser is not part of the application itself.  That is how does a JOSE application know that the built in (assuming there is one) parser for the FOO language/environment it is operating in will correctly do the detection for it and not use the rule of grab the last value.

I would also be open to the argument that a streaming parser is not really an entire parser and the thing that consumes the output of a streaming parser could be the entity that enforces the uniqueness requirement.  


> -----Original Message-----
> From: Nico Williams []
> Sent: Saturday, July 06, 2013 6:20 PM
> To:
> Cc: Jim Schaad
> Subject: Re: [Json] Proposed minimal change for duplicate names in objects
> On Sat, Jul 6, 2013 at 7:13 PM, Jim Schaad <> wrote:
> > Tim is not the only person saying this.  The JOSE working group has
> > this as a requirement to be enforced in the documents it is producing.
> > Specification that JOSE objects MUST fail validation if there are
> > duplicate names in an object.
> But does it follow (did you even mean to say) that since JOSE wants
> requirement X (no dup names here) JSON should have it itself?
> One might argue that otherwise JOSE implementations would have to use
> JSON parsers that implement JOSE's requirement even though JSON doesn't
> have the same requirement.  But then. JOSE implementations also could use
> streaming JSON parsers and check for dup names themselves.  So I don't
> think JOSE's requirement adds anything new to the discussion.
> We still need to decide (directly or indirectly) whether to impose dup name
> checking on all JSON parsers, even minimal-state streaming parsers,
> whether we want to impose a requirement on the parser and the application
> (so we need not mention streaming), or on the parser if it's not a streaming
> parser *and* the application if the parser is streaming.
> My view (for whatever it counts) is that we don't have consensus [yet] for
> imposing a requirement on parsers to reject objects with dup names.  We've
> had at least a number of examples of streaming parsers that cannot
> implement such a requirement -- the whole point of streaming being
> nullified by state-keeping requirements like this one.
>  So we'd have to explicitly decide that we don't want to allow minimal state
> streaming parsers.  Might as well call for consensus on that.
> Nico
> --