Re: Next Steps on JSON + Proposed TAG Resolution

On Fri, Oct 18, 2013 at 11:48 AM, Douglas Crockford
<douglas@crockford.com>wrote:

> 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<Daniel.Appelquist@telefonica.com>
>>     <mailto:Daniel.Appelquist@**telefonica.com<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
>>     >>
>>     >
>>
>>
>>
>
Other, unofficial, non-spec things that describe in more humane ways things
that specs formalize are common place though - I'm not suggesting that Doug
take it down, just cite/link to 404.  json.org isn't an official spec as
recognized by any standards body - it is a really good description for
people who want to understand it.

-- 
Brian Kardell :: @briankardell :: hitchjs.com