JSON Duplicate Keys

Brendan Eich 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).

/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
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130609/2bb40686/attachment.html>


More information about the es-discuss mailing list