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

On Thu, Feb 28, 2013 at 1:59 PM, Tim Bray <tbray@textuality.com> wrote:
> If there were a significant number of protocols, or deployed software
> components, that relied on the use of multiple keys, then changing the
> SHOULD to a MUST would be a breaking change. I do not believe that there are
> any, and thus this is not, *de facto*, a breaking change.  That hypothesis
> is easily falsified, if in the course of the IETF work someone sticks their
> hand up and says “this is going to break me”.  But I’m not holding my
> breath.

+1 on this.

One minor comment on latter part -- in cases where parsers do not
retain more state than absolutely required for matching open scopes
(aka "streaming parsers"), this would presumably mean no change, as
all key/value pairs would still be exposed as is. It would then be up
to higher layers, such as tree builder or data-binder, to ensure that
of possible duplicates the last one sticks. This is how many tools
already work.
I just want to mention this as it is one case where wording could
still be debated ("but parser SHOULD remove other values, only expose
last one"), depending on wording.

-+ Tatu +-

>
>  -T
>
>
> On Thu, Feb 28, 2013 at 1:51 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>
>> On Feb 28, 2013, at 12:46 PM, Nico Williams <nico@cryptonector.com> 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.
>>
>> ...but the former ("say senders MUST NOT send dup object keys") breaks it,
>> given that the RFC had a SHOULD not a MUST. Thus the question in this
>> thread.
>>
>> --Paul Hoffman
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json
>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>