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

Stephan Beal <> Sun, 07 July 2013 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6F6221F9446 for <>; Sun, 7 Jul 2013 11:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aeBgoTnLPlA9 for <>; Sun, 7 Jul 2013 11:09:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22c]) by (Postfix) with ESMTP id 977DE21F91CE for <>; Sun, 7 Jul 2013 11:09:37 -0700 (PDT)
Received: by with SMTP id c10so8397640wiw.11 for <>; Sun, 07 Jul 2013 11:09:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=IXDJYONJAPHpP4SgqYnQ6FapfViQCQz2LGvhP2Qod1I=; b=RVRpII7A4mDd3Qg9avhMAwXHmv203fi6ulYq/IBvjxuCLh9MgN0xQ5qDYeP49SfZst WaE/XaUD43jskJzWWtUF2jr1MIjBzEW3qceYcbCqYCwNEfSUHk/wTC0grVvlDUGdkDf5 JOhJzhKf5bk+kv9n9qWMV+1ZRezcBagzEXthW+NqETc3GUGpvKUykehxilrgoJLBld+U rC28NML1o3Hd2B3aD7lK9ZiEb4aQBEtUri/AgUTV91h56iYuLhe/0460dUmlCrFRD/ya /Xmh8KFSXqYQe30pCgJmYfPe9q5FJdReuQfE6suk1JQBTwzyTm2t8Ew045rXMO53cHR+ R45Q==
MIME-Version: 1.0
X-Received: by with SMTP id k4mr12198427wiy.0.1373220576707; Sun, 07 Jul 2013 11:09:36 -0700 (PDT)
Received: by with HTTP; Sun, 7 Jul 2013 11:09:36 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <00cd01ce7a9f$19adeaa0$4d09bfe0$> <00d701ce7aa6$cc5fe700$651fb500$> <>
Date: Sun, 7 Jul 2013 20:09:36 +0200
Message-ID: <>
From: Stephan Beal <>
To: "" <>
Content-Type: multipart/alternative; boundary=f46d044281ceac4e5804e0efd4e0
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 18:09:38 -0000

On Sun, Jul 7, 2013 at 3:20 AM, Nico Williams <> wrote:

> 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.

FWIW, as a JSON library implementor, i can say that a MUST on the whole
duplicate keys issue is not going to be enforced in any of my impls. Having
to check for an existing key on every insert turns O(N) operations in to
catastrophically poor operation if the property store is not fast (and JSON
has no business specifying performance characteristics). e.g. my JSON
libraries tend to use simple key/value pair _lists_, not maps, because the
nature of JSON is (for most apps) such that it's spit out and slurped in,
but not manipulated as the basic data structure (at least not in C, where
i'm working). Streaming or not, enforcing the implied level of
infrastructure and potential performance hits which MUST  implies is not
something i plan on doing, even if it means not being fully compliant.
"Duplicate keys lead to unspecified behaviour," end of story.

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.

i'm for not splitting them into categories, as this document really has no
business (IMO) specifying that level of implementation detail. Specify the
duplicate keys as poor practice leading to
unspecified/implementation-defined behaviour, and be done it.

----- stephan beal