JSON Duplicate Keys
brendan at mozilla.com
Sun Jun 9 19:25:59 PDT 2013
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).
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
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
AR: It's possible to ignore this change?
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
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.
* 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.
> Here are the notes from the first TC39 meeting that this topic was
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss