Re: Next Steps on JSON + Proposed TAG Resolution

ECMA-262 Sixth edition (aka ECMAScript) will not contain the JSON 
grammar. It will instead have a normative reference to ECMA-404.

On 10/18/2013 8:07 AM, Brian Kardell wrote:
>
>
> On Oct 18, 2013 11:02 AM, "Tim Bray" <tbray@textuality.com 
> <mailto:tbray@textuality.com>> wrote:
> >
> > Based on my current understanding, I would argue, in the IETF 
> context, against making such a change. Here’s why:
> >
> > - I don’t see any benefit to the reader of any spec in sending them 
> to look somewhere else unless doing so conveys valuable new 
> information, and 404 doesn’t.
> >
> > - There are now 4 places that specify the syntax of JSON: json.org 
> <http://json.org>, RFC4627, EcmaScript 5.1, and now Ecma 404.  They 
> all agree, as anyone can see by observing the success of JSON in the 
> wild. The syntax of JSON has in fact been entirely stable for over a 
> decade, it interoperates very well, and there is no disagreement on 
> the subject except about the very-well-documented restriction 
> introduced in RFC4627 on the top-level constructs.  I see no evidence 
> to support the assertion that any of these are any more canonical than 
> any of the others.
> >
> Doug probably controls json.org <http://json.org>, it could pretty 
> easily be updated to cite and link to 404.
>
> > - The claim that a mini-spec rushed out in late 2013 without any 
> consultation outside an Ecma committee is the single canonical 
> definition for a ubiquitous Internet data format that’s been stable 
> for over a decade: Counter-intuitive and lacks supporting evidence.
> >
> > - The notion that any particular standards group has a claim to 
> “ownership” of JSON: Offensive, because JSON belongs to its community 
> of users.
> >
> > - Of the many specifications of JSON, I don’t think Ecma 404 is the 
> best. First, railroad diagrams are less helpful to implementers than 
> ABNF.  Second, obvious mistakes like the first paragraph of section 9 
> don’t inspire confidence that it’s received an adequate level of peer  
> review.  Third, compared to EcmaScript 5.2 section 6, it lacks the 
> careful attention to detail about what it means by terms such as 
> “character”, instead asserting (surprisingly) that a string is a 
> sequence of “Unicode code points” which strictly speaking would 
> disqualify {"a":"\uDEAD"} since U+DEAD isn’t a  code point; JSON as 
> she are spoke allows “\uDEAD” and trying to retroactively fix this is 
> inappropriate.
> >
> > - There has been an IETF RFC for some number of years that defines 
> the term “JSON Text” and restricts its usage to arrays/objects. 
> Implementors have felt entitled to ship software based on that 
> language and it’s hard to justify either removing or ignoring it.
> >
> > - I hear arguments that unless everyone defers to one spec, it opens 
> the door to interoperability problems. I don’t believe them. JSON as 
> it exists has excellent interoperability and nobody is trying to 
> change it.  The ways to avoid the small number of corner-case interop 
> problems are well understood (and carefully documented in the 4627bis 
> draft).
> >
> >
> > On Thu, Oct 17, 2013 at 12:39 PM, Appelquist Daniel (UK) 
> <Daniel.Appelquist@telefonica.com 
> <mailto:Daniel.Appelquist@telefonica.com>> wrote:
> >>
> >> Hia folks --
> >>
> >> Thanks for being a part of today's call.
> >>
> >> Regarding our discussion today on JSON, which I though twas very 
> fruitful
> >> in terms of clarifying the positions involved: it sounds like if we 
> want
> >> to influence the work in IETF that is imminently going to IETF last 
> call
> >> that we need to move quickly. I suggest that we should do so on the 
> basis
> >> of a TAG resolution. In order to move quickly on this I would like to
> >> suggest that we craft this resolution and approve it in email 
> rather than
> >> waiting for the next f2f.
> >>
> >> My straw man proposed resolution is based on my suggestion which I 
> heard
> >> Doug Crockford also state and which also seemed to be echoed by 
> Philippe's
> >> comments. It would read as follows:
> >>
> >> --
> >> The TAG resolves to request that the IETF JSON working group amend the
> >> current working draft of their JSON spec (rfc4627bis) to include a
> >> normative reference to the appropriate ECMA published specification
> >> (ECMA-404), and to clearly state that ECMA-404 is the authoritative
> >> specification with regard to JSON grammar.
> >> --
> >>
> >> Any comments?  Do you think that as a group we can reach consensus 
> on this
> >> or a similarly worded resolution? If so then I think this could 
> form the
> >> basis for our collective action, including individual contributions 
> to the
> >> IETF working group, a more fully fleshed out TAG statement on the topic
> >> (to be crafted in a similar manner to our other working group feedback)
> >> and potentially a liaison communication from the W3C to IETF along 
> these
> >> lines.
> >>
> >> Make sense?  Comments?
> >> Dan
> >>
> >
>

Received on Friday, 18 October 2013 17:14:29 UTC