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

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<tbray@textuality.com>  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
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json