- From: Douglas Crockford <douglas@crockford.com>
- Date: Fri, 18 Oct 2013 11:48:13 -0700
- To: Tim Bray <tbray@textuality.com>, Brian Kardell <bkardell@gmail.com>
- CC: Philippe Le Hégaret <plh@w3.org>, "www-tag@w3.org" <www-tag@w3.org>, Wendy Seltzer <wseltzer@w3.org>, "Appelquist Daniel, (UK)" <Daniel.Appelquist@telefonica.com>
It is my favorite too. But I have never been able to convince a committee to accept it. On 10/18/2013 11:45 AM, Tim Bray wrote: > On Fri, Oct 18, 2013 at 8:07 AM, Brian Kardell <bkardell@gmail.com > <mailto:bkardell@gmail.com>> wrote: > > Doug probably controls json.org <http://json.org>, it could pretty > easily be updated to cite and link to 404. > > > Confession: Of all the different JSON descriptions, json.org > <http://json.org> is by far my favorite. It’s a brilliant little > technical tutorial and I think partially responsible for JSON’s > immense success. -T > > > - 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 18:48:53 UTC