Re: [Json] What does "break compatibility" mean?

Paul Hoffman <> Fri, 01 March 2013 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CE4021E8053 for <>; Fri, 1 Mar 2013 07:31:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.685
X-Spam-Status: No, score=-102.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 939VsyvtZWVh for <>; Fri, 1 Mar 2013 07:31:07 -0800 (PST)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id EBEDB21E8051 for <>; Fri, 1 Mar 2013 07:31:06 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id r21FV4WQ095965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <>; Fri, 1 Mar 2013 08:31:05 -0700 (MST) (envelope-from
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Fri, 01 Mar 2013 07:31:05 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <00b001ce1509$c4c99fc0$4e5cdf40$> <> <> <> <> <>
To: "" <>
X-Mailer: Apple Mail (2.1499)
Subject: Re: [Json] What does "break compatibility" mean?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Mar 2013 15:31:07 -0000

On Mar 1, 2013, at 2:01 AM, Martin J. Dürst <> wrote:

> Putting the horse before the chart, I think we don't want to break compatibility, but where necessary, we want to improve interoperability. Senders that send two of the same keys in the same object, and receivers that take any other than the last one, both create interoperability problems. Fixing that is valuable progress.


> Using a standard language lawyer approach, I think we can observe that changing the SHOULD NOT to a MUST NOT should be okay because SHOULD NOT means that you can do it if you have a really good reason for it, but I haven't yet seen anybody come up with a good reason for it, so I'd claim that the cases with duplicate keys that exist out in the wild actually don't comply to the current spec.

That's not true at all. A perfectly valid reason for a JSON producer to put in two or more of the same name is a streaming producer that doesn't know what has been added before. Changing SHOULD NOT to MUST NOT means that a JSON producer MUST know everything else in the object before emitting it. It would be reasonable for this to be the consensus, but we can't say that it does not break compatibility with some producers. (And, of course, the other option is to break compatibility with some JSON processors.)

--Paul Hoffman