Re: Next Steps on JSON + Proposed TAG Resolution

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