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

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 01 Mar 2013 19:01:25 +0900

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.

The result of the two approaches above is the same, something like the 
lanugage that Nico proposed.

Regards,   Martin.

On 2013/03/01 5:46, Nico Williams wrote:
> On Thu, Feb 28, 2013 at 2:06 PM, Tim Bray<[email-masked]>  wrote:
>> It’s clear to me that, *for the purposes of the IETF*, someone needs to say
>> “People sending JSON MUST NOT use duplicate keys.”  The fact that certain
>> libraries allow less-clueful developers to do this, and that parsing
>> software is observed to behave unpredictably when they do, should only
>> encourage us.
>
> The obvious compromise is to say senders MUST NOT send dup object keys
> and receivers MUST take the last key value pair of any dup keys,
> per-ECMAScript.  The latter preserves compatibility.
>
> Nico
> --
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Mar 2013 07:31:05 -0800

On Mar 1, 2013, at 2:01 AM, Martin J. Dürst <[email-masked]> 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.

Yes.

> 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