Re: JSON feedback we could submit

On 2013/11/12 16:42, Appelquist Daniel (UK) wrote:

> First of all, thanks to Martin for forwarding the last call note and
> reminding us about the IETF participation model and the importance of
> individual comments.

Well, well. Actually, I forgot to point out that you should use the same 
subject line as the last call when you submit comments, so that it's 
easier for the IESG and others to sort out things.

> In addition to TAG members making individual
> comments, we have also bee encouraged to facilitate an official liaison
> statement.  In the interest of transparency I am posting this to our
> public list but this is a draft and the official version of this statement
> will be sent through the official liaison channel.

> Please post comments here - as discussed I would like to finalize this
> soon so we can get it sent over in a timely fashion.
>
> My suggested DRAFT text for such a liaison (incorporating Anne’s example)
> is as follows:
>
> --
>
> The W3C Technical Architecture Group has a concern regarding the ongoing
> coordination of the industry standardization work on JSON.  JSON is a key
> integration technology for Web applications and a key data interchange
> format for the Web.  The current state of affairs, where there are now two
> different JSON specifications, one developed in ECMA as ECMA-404 and one
> developed in IETF as RFC-4627 and in last call as RFC-4627bis is not ideal

There's an 'and' missing between these two lines.

> could lead to confusion in the industry.  We believe that this could lead
> to interoperability issues.  The fact that the two specs vary slightly
> underscores this concern.

I don't get the last sentence. Does it mean that if the two specs would 
vary more, there would be less of a concern for interoperability issues? 
Or does it mean that if the two specs didn't vary at all, there still 
would be a concern for interoperability issues? I suggest rewording the 
last two sentences as:

Because the two specs vary slightly, we believe this could lead to 
interoperability issues.

(or something similar)


> For example, JSON parsers exists that can parse "42" today and parsers
> that cannot parse "42" today can be meaningfully upgraded to do so too.
> This would not break those parsers, unless they depend on parsing 42 as an
> error, which is a far more unlikely scenario than parsing it as 42 given
> precedence.

This text is fine for somebody who knows what ECMA-404 says, and what 
RFC-4627bis says. But your comment will go to the wider IETF community 
and to the IESG, most members of which may not be very familiar with the 
details.

So I propose to reword this e.g. as follows (also taking into account my 
earlier discussion with Anne, where I'm not sure we reached agreement or 
not, and fixing grammar (parsers exists)):

 >>>>
For example, today there are JSON parsers (conforming to ECMA-404) that 
can parse "42" (a JSON document consisting of a single integer). There 
are also parsers (conforming to RFC 4627/draft-ietf-json-rfc4627bis-07) 
that cannot parse "42" today, but they can be meaningfully upgraded to 
do so too. This would not break applications using those parsers, unless 
they depend on parsing "42" as an error, which is a far more unlikely 
scenario than parsing it as 42 given precedence.
 >>>>

Actually, I'm having problems with the last word, 'precedence'. The OED 
defines it as "the condition of being considered more important than 
someone or something else; priority in importance, order, or rank", 
Webster as "the condition of being more important than something or 
someone else and therefore coming or being dealt with first". So is the 
point here to say that 42 is more important than an error? If yes, what 
would support such a conclusion? I'm somewhat suspecting that the 
intended meaning was something else, in which case it should be another 
word that "precedence".

Also it would be good to have more examples (or a complete list) of 
other differences, and how they can be aligned. Like many other 
standards organizations, the IETF appreciates technical detail 
(including proposals for actual text changes). But of course any comment 
is better than no comment.


> Regardless of the historical reasons for the current situation, the W3C
> TAG believes that having one definition of JSON would be beneficial for
> the Web and for the wider community of JSON implementors and JSON
> consuming and producing applications.  We suggest that the IETF JSON
> working group should re-enter discussions with ECMA TC39 in order to
> facilitate aligning RFC-4627bis with the current ECMA-404 specification.

Here, when asking for "one definition", is this asking for a definition 
in a single place, or for one definition in the sense that if there are 
definitions in two places, they should say exactly the same? When 
reading the paragraph, I first thought the former, but "aligning" feels 
more like the later. (Of course, if you want to keep this fuzzy, that's 
your choice.)

Regards,   Martin.

Received on Tuesday, 12 November 2013 09:10:23 UTC