JSON Duplicate Keys

Brendan Eich brendan at mozilla.com
Mon Jun 10 09:31:22 PDT 2013


Paul Hoffman wrote:
> The term "incompatible change" is being used too loosely here. RFC 
> 4627 and the ES spec are currently different. If we simply republished 
> RFC 4627, it would be an incompatible change from ES. If we publish a 
> new RFC that says exactly what ES says, it will be an incompatible 
> change from the earlier RFC.

Right, that's a good point -- something has to give.

In case it wasn't obvious, most TC39 folks generally believe the 
"something" is the de-jure spec when de-facto practice (built on 
another, later spec -- or built on no spec atll) is in conflict. Not all 
TC39ers, and not all the time -- if something is so broken by design as 
to be unused in practice outside of tests, we may try to break backward 
compatibility. I observe that such cases are few.

> Developers have read both documents and dealt with the 
> incompatibilities however they felt appropriate.

Developers also are constrained in the market to interoperate, most of 
the time (we hope; I lived through the IE nuclear winter of near-95% 
market share and fought back with Firefox; we're living through the 
"mobile Web == iOS WebKit" era, with an end in sight finally).

So what actually works, the "intersection semantics" among popular 
implementations, is what we ought to spec. That's something most TC39ers 
agree on, most of the time, too.

This says to me that changing the RFC is the best course. People reading 
will, I'm sure, let me know if I'm missing anything!

/be

>
> --Paul Hoffman
>
>
> On Sun, Jun 9, 2013 at 7:25 PM, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> wrote:
>
>     Paul Hoffman wrote:
>>     Thanks, but that doesn't match what Yehuda said. If anything, it
>>     shows that there is as widespread disagreement within TC39 as to
>>     what is a "breaking" change with respect to duplicate names in
>>     objects as there so far is in the JSON WG.
>
>     The minutes Rick cited show no disagreement other than Doug (I
>     missed this part of the March meeting). The "FTR: Majority
>     opposition, no consensus" note, I believe, means that everyone but
>     Doug agreed that an incompatible change was a bad idea, to be opposed.
>
>     Is anything else unclear? Am I missing some other notes section? I
>     do not see "widespread disagreement within TC39 as to what is a
>     "breaking" change with respect to duplicate names in objects" in
>     any of the "JSON, IETF changes" meeting notes text (cited below).
>
>     /be
>
>
>         <https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-03/mar-12.md#49-json-ietf-changes>4.9
>         JSON, IETF changes
>
>     (Presented by DC Crockford)
>
>     Currently, JSON is an RFC, informational, the IETF version will be
>     an internet standard and there is a minor correction that affects
>     ECMAScript.
>
>     The use of "should" in 15.12.2
>
>     AR: What is the motivation of the change?
>
>     DC: The change involves the mistake of using "should" w/r to
>     multiple same-named keys error. Multiple same-name keys are
>     invalid and /must/ throw an error (vs. "should" throw an error)
>
>     LH: This is a breaking change
>
>     DH: The worst being the use case of multiple, same-named keys as
>     comments
>
>     DC: That's stupid
>
>     YK: That's based on on your recommendation to use a keyed entry as
>     a comment, so people naturally used the same key, knowing they'd
>     be ignored.
>
>     DC: I would certainly never recommend that practice
>
>     YK: It was a side-effect
>
>     AR: Which key is used now?
>
>     AWB: The last one wins.
>
>     AR: Is that the root of the security vector?
>
>     DC: Not in ES, but in other encodings
>
>     AR: Order matters, unescaped content that follows...
>
>     DC: The current spec says "[they should not]", but will say "[they
>     must now]"
>
>     YK: Let's define an ordering and make it cryptographically secure.
>
>     DC: (recapping to Mark Miller, who just arrived)
>
>     MM: You can't do that. (laughs)
>
>     MM: You can't change "should" to "must"
>
>     YK: Agreed, you cannot change JSON, there are too many JSON
>     documents in existence.
>
>     MM: Agreed.
>
>     AR: It's possible to ignore this change?
>
>     DC: Yes
>
>     DH: Then why are we creating a dead letter?
>
>     MM: ES has a grammatical specification for validating and parsing
>     JSON. Anything that is not conformant JSON, would not parse. This
>     change loses that property.
>
>     DC: Or we don't change the spec
>
>     MM: The way that you properly reject our favorite fixes, I think
>     you should apply to your favorite fixes
>
>     DC: I'll consider that
>
>     AR: There is considerable opposition to this change
>
>     DC: Two choices...
>
>      1. Make it an error
>      2. Continue to take the last one
>
>     DC: Decoders have license to do what they want with non-conformant
>     material. Encoders /must/ be conferment to new changes.
>
>     MM: Our current encoder conforms...
>
>     AWB: I don't think it does... reviver/replacer
>
>     MM: No, can only apply objects instead of the original objects.
>
>     AR: Did not realize the production/consumption distinction of this
>     change.
>
>     WH: Supports this change. ECMAScript is already conformant because
>     it never generates duplicate keys.
>
>     MM: With this change ECMAScript would have two unappealing
>     choices: A. No longer be a validating parser (i.e. a parser that
>     doesn't allow any optional syntax or extensions, even though
>     extensions are permitted by the JSON spec). B. Do a breaking
>     change by throwing errors when seeing duplicates when parsing.
>
>
>             <https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-03/mar-12.md#conclusionresolution>Conclusion/Resolution
>
>       * Revisit this, after DC has made a final decision.
>       * FTR: Majority opposition, no consensus.
>
>
>>
>>     If there are other public minutes that relate to the TC39-IETF
>>     relationship, I'd certainly appreciate them. The ECMA-IETF
>>     discussions all happened before Matt Miller and I were made
>>     co-chairs of the WG.
>>
>>     --Paul Hoffman
>>
>>
>>     On Sun, Jun 9, 2013 at 4:53 PM, Rick Waldron
>>     <waldron.rick at gmail.com <mailto:waldron.rick at gmail.com>> wrote:
>>
>>
>>
>>
>>         On Sun, Jun 9, 2013 at 7:19 PM, Paul Hoffman
>>         <paul.hoffman at gmail.com <mailto:paul.hoffman at gmail.com>> wrote:
>>
>>             >At two TC39 meetings, members of TC39 expressed deep
>>             concern about the prospect of incompatible changes to
>>             JSON by the IETF.
>>
>>             Those concerns have not been expressed directly to the
>>             IETF's JSON Working Group. I say this as one of the two
>>             co-chairs of the JSON WG. If TC39 wants to express "deep
>>             concern", they certainly know where to do so. Them doing
>>             so sooner rather than later would be helpful all around.
>>
>>             I would note that some of the possibly-incompatible
>>             changes to RFC 4627 that are being discussed relate to
>>             places where the RFC is self-contradictory or blatantly
>>             unclear. In such cases, leaving the RFC alone might just
>>             as easily lead to incompatible implementations as
>>             clarifications would. That is going to have be determined
>>             by the IETF's consensus process.
>>
>>             No one can force anyone here to follow the official WG
>>             discussion for the successor to RFC 4627, of course.
>>             However, given that some people on this list are JSON
>>             experts, if you don't want to participate in the
>>             evolution of the RFC, I would be interested in hearing
>>             (possibly off-list) why that is. Part of the job of the
>>             chairs is to make sure experts feel welcome in the IETF
>>             process.
>>
>>
>>         Paul,
>>
>>         Here are the notes from the first TC39 meeting that this
>>         topic was discussed
>>
>>         https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-03/mar-12.md#49-json-ietf-changes
>>
>>         Rick
>>
>>
>>     _______________________________________________
>>     es-discuss mailing list
>>     es-discuss at mozilla.org  <mailto:es-discuss at mozilla.org>
>>     https://mail.mozilla.org/listinfo/es-discuss
>
>


More information about the es-discuss mailing list