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

Paul Hoffman <> Wed, 03 July 2013 15:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3371811E81B4 for <>; Wed, 3 Jul 2013 08:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ap4sIKAKnHue for <>; Wed, 3 Jul 2013 08:15:19 -0700 (PDT)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id D37C511E81CF for <>; Wed, 3 Jul 2013 08:15:18 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id r63FFD2f050579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Jul 2013 08:15:14 -0700 (MST) (envelope-from
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Wed, 3 Jul 2013 08:15:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Nico Williams <>
X-Mailer: Apple Mail (2.1508)
Cc: " WG" <>
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: Wed, 03 Jul 2013 15:15:20 -0000

<chair hats on>

On Jul 2, 2013, at 8:30 PM, Nico Williams <> wrote:

> No way.  The threads on this were long, I know, but it should be clear
> that streaming parsers cannot even detect that there are duplicates,
> much less do something about them.

The earlier threads indicated that some people felt streaming parsers could not retain the names they had emitted, while others didn't. 

> In short, for streaming parsers (and generators) there's nothing we can do.

The more recent threads indicated that predictable interoperability was important to many people on the list.

The purpose of this thread, and its companion, is to propose changes to the spec that would be to see if there is rough consensus for proposals that bring predictable interoperability. If such rough consensus is not possible, that is valuable input for the Working Group.

--Matt Miller and Paul Hoffman