Subject: [Json] I-D Action: draft-ietf-json-rfc4627bis-05.txt

From: [email-masked]
Date: Tue, 08 Oct 2013 16:48:10 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the JavaScript Object Notation Working Group of the IETF.

	Title           : The JSON Data Interchange Format
	Author(s)       : Tim Bray
	Filename        : draft-ietf-json-rfc4627bis-05.txt
	Pages           : 15
	Date            : 2013-10-08

Abstract:
   JavaScript Object Notation (JSON) is a lightweight, text-based,
   language-independent data interchange format.  It was derived from
   the ECMAScript Programming Language Standard.  JSON defines a small
   set of formatting rules for the portable representation of structured
   data.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-json-rfc4627bis-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tim Bray <[email-masked]>
Date: Tue, 8 Oct 2013 16:50:12 -0700

Real HTML at https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-05.html

On Tue, Oct 8, 2013 at 4:48 PM, <[email-masked]> wrote:

> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 9 Oct 2013 11:38:52 +1100

> Real HTML at https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-05.html

Editorial:
 “for example, "Hello world!", "42", and "true" would all be valid JSON texts in the ECMAScript 5.1 context.”

This is not quite precise as the double-quotes are part of the JSON text for the string example, but not for the number and Boolean examples. Perhaps say:
 
  for example, each of the following 3 lines would be a valid JSON text
  in the ECMAScript 5.1 context:
 
  "Hello world!"
  42
  true 

But the publication of ECMA-404 means we should radically change 4627bis.
Lets do what ECMA-404 "Introduction" suggests other standards do:

  It is expected that other standards will refer to this one, strictly
  adhering to the JSON text format, while imposing restrictions on various
  encoding details. Such standards may require specific behaviours. JSON 
  itself specifies no behaviour. 

Lets reference ECMA-404 -- not repeating any of the syntax.
Define the media type.
Discuss the interop issues with surrogates, huge integers, decimal floats, duplicate names, comments, encodings.
Perhaps define terms such as "web-safe JSON" (for a subset of JSON) and "web-safe JSON parser" (for specific parser behaviour) that other specs using JSON can refer to.

I guess this is close to Tim’s "Internet JSON" or "I-JSON" proposal.
It is time to drop the minimal 4627 update.

--
James Manger

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Oct 2013 13:26:23 -0700

<no hat>

> It is time to drop the minimal 4627 update.

A strong -1 on ripping out our syntax and pointing to ECMA-404. Our syntax matches their syntax, so there is not a conflict issue. ECMA-404 was supposed to be syntax-only, but they included semantics about Unicode (characters vs. code points) that were important enough to this WG to generate hundreds of messages on our mailing list. If we point to ECMA-404 for the syntax only, and add in our semantics on interoperability, there will then be a conflict that will have a negative effect on developers who are trying to create interoperable implementations.

--Paul Hoffman

---

From: Larry Masinter <[email-masked]>
Date: Wed, 9 Oct 2013 15:23:15 -0700

If it's "no hat":
    are you saying you think ECMA-404 is unsuitable as a normative reference for 4627bis, because it's handling of Unicode semantics is incorrect? 
Is the problem technical or political?

(Number of emails on a subject is not a good metric of controversy, just of familiarity.)

> -----Original Message-----J
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Hoffman
> Sent: Wednesday, October 09, 2013 1:26 PM
> To: Manger, James H
> Cc: [email-masked]
> Subject: [Json] Radically changing 4627bis
> 
> <no hat>
> 
> > Perhaps define terms such as "web-safe JSON" (for a subset of JSON) and
> "web-safe JSON parser" (for specific parser behaviour) that other specs using
> JSON can refer to.
> >
> > I guess this is close to Tim's "Internet JSON" or "I-JSON" proposal.
> A strong -1 on ripping out our syntax and pointing to ECMA-404. Our syntax
> matches their syntax, so there is not a conflict issue. ECMA-404 was supposed to
> be syntax-only, but they included semantics about Unicode (characters vs. code
> points) that were important enough to this WG to generate hundreds of
> messages on our mailing list. If we point to ECMA-404 for the syntax only, and
> add in our semantics on interoperability, there will then be a conflict that will
> have a negative effect on developers who are trying to create interoperable
> implementations.
> 
> --Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Oct 2013 00:32:34 +0200

On Oct 10, 2013, at 00:23, Larry Masinter <[email-masked]> wrote:

> are you saying you think ECMA-404 is unsuitable as a normative reference for 4627bis

If the core of 404 is "syntax", I prefer ABNF over car racing.

We then still have to specify the rest.

Grüße, Carsten

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Oct 2013 16:31:19 -0700

>    are you saying you think ECMA-404 is unsuitable as a normative reference for 4627bis, because it's handling of Unicode semantics is incorrect? 

No, that's not what I said.

> Is the problem technical or political?

Technical.

> (Number of emails on a subject is not a good metric of controversy, just of familiarity.)

And that's not what I said either. I said "important"; note the difference?

--Paul Hoffman

---

From: Tim Bray <[email-masked]>
Date: Wed, 9 Oct 2013 16:32:03 -0700

The descriptions in ECMA 404 and 4627 and json.org and ECMA 262 and the
-bis draft are all isomorphic as respects JSON syntax.  Except for the ECMA
family doesn't impose the top-level array-or-object restriction.  Also 404
says nothing at all about dupes in objects and loses a few other bits &
pieces such as default encodings.

Thus there would be no benefit to a reader of -bis in making them go
anywhere else to learn the syntax because it’s the same everywhere.  So I
think the -bis draft helpfully covers the same syntax ground, while also
offering interoperability-problems advice.  I don’t see any benefit in
decomposing the -bis at this point.

On Wed, Oct 9, 2013 at 1:26 PM, Paul Hoffman <[email-masked]> wrote:

> > Discuss the interop issues with surrogates, huge integers, decimal
> floats, duplicate names, comments, encodings.
> "web-safe JSON parser" (for specific parser behaviour) that other specs
> using JSON can refer to.
> >
> matches their syntax, so there is not a conflict issue. ECMA-404 was
> supposed to be syntax-only, but they included semantics about Unicode
> (characters vs. code points) that were important enough to this WG to
> generate hundreds of messages on our mailing list. If we point to ECMA-404
> for the syntax only, and add in our semantics on interoperability, there
> will then be a conflict that will have a negative effect on developers who
> are trying to create interoperable implementations.
>
> --Paul Hoffman

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 10 Oct 2013 11:38:56 +1100

> -bis draft are all isomorphic as respects JSON syntax.  Except for the
> ECMA family doesn't impose the top-level array-or-object restriction.

One "Except for" is almost enough reason not to rewrite the syntax in -bis.
Particularly as 404's removing of the top-level-is-array-or-object restriction
is NOT exactly the same as using the <value> ABNF production instead
of the <JSON-text> production in -bis. <value> doesn't allow whitespace around
strings, numbers, booleans, and null, while ECMA 404 does.

To be consistent with ECMA 404, 4627bis ABNF would need to be slightly adjusted.
From:
  value = false / null / true / object / array / number / string
To:
  value = ws ( false / null / true / object / array / number / string ) ws

> anywhere else to learn the syntax because it’s the same everywhere.

Conversely there is no benefit in making every reader wonder if there are
subtle differences between the ABNF-based syntax in -bis and the
tokens+racetrack description in 404.

Including 1 example JSON value in -bis would be sufficient for readers
not to have to return to 404 to remember (or even learn) the syntax.

--
James Manger

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 10 Oct 2013 13:05:06 +0900

[most probably off topic]

On 2013/10/10 7:32, Carsten Bormann wrote:
> On Oct 10, 2013, at 00:23, Larry Masinter<[email-masked]>  wrote:
>

I assume that "car racing" refers to a style of specification close to 
pseudocode, with step-by-step descriptions.

How did this get the name "car racing"?

Regards,   Martin.

---

From: John Cowan <[email-masked]>
Date: Thu, 10 Oct 2013 00:33:02 -0400

"Martin J. Dürst" scripsit:

> I assume that "car racing" refers to a style of specification close
> to pseudocode, with step-by-step descriptions.

Not at all.  See <https://en.wikipedia.org/wiki/Syntax_diagram>.
There are usually called "railroad diagrams", at least by me.

-- 
You are a child of the universe no less         John Cowan
than the trees and all other acyclic            http://www.ccil.org/~cowan
graphs; you have a right to be here.            [email-masked]
  --DeXiderata by Sean McGrath

---

From: Tim Bray <[email-masked]>
Date: Wed, 9 Oct 2013 22:00:12 -0700

James Manger’s suggestion below is obviously good and I’ll adopt it unless
someone has a good reason not to. -T

On Tue, Oct 8, 2013 at 5:38 PM, Manger, James H <
[email-masked]> wrote:

> This is not quite precise as the double-quotes are part of the JSON text
> for the string example, but not for the number and Boolean examples.
> Perhaps say:
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 10 Oct 2013 14:42:58 +0900

On 2013/10/10 13:33, John Cowan wrote:
> Not at all.  See<https://en.wikipedia.org/wiki/Syntax_diagram>.

Oh, I see. So it's not about specification style, just about notation.

Regards,   Martin.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Oct 2013 09:32:43 +0200

> Oh, I see. So it's not about specification style, just about notation.

Yes, sorry for being opaque.  (When they were popular in the 1970s, we sometimes derided them as "Rennbahndiagramme", "racetrack diagrams".)

I can put the ABNF into tools.  Harder to do that with those nice figures.
These have the higher tutorial value, though, and are more accessible to people without CS background.
(Instead of trying to be a complete notation, they rely on the text, e.g. "hexadecimal digits".)

More generally speaking, I read ECMA 404 as a nice JSON tutorial, which it does quite well.
If I can get someone to read only 6 pages about JSON, these are the ones I'd suggest.

As with most tutorials, it wins by not addressing some of the more difficult issues.

Grüße, Carsten

---

From: "Markus Lanthaler" <[email-masked]>
Date: Thu, 10 Oct 2013 12:33:41 +0200

On Thursday, October 10, 2013 1:32 AM, Tim Bray wrote:
> The descriptions in ECMA 404 and 4627 and json.org and ECMA 262 and the -bis
> draft are all isomorphic as respects JSON syntax.  Except for the ECMA

+1

--
Markus Lanthaler
@markuslanthaler

---

From: Jorge Chamorro <[email-masked]>
Date: Thu, 10 Oct 2013 13:48:27 +0200

On 10/10/2013, at 01:32, Tim Bray wrote:

> Thus there would be no benefit to a reader of -bis in making them go anywhere else to learn the syntax because it’s the same everywhere.

The way I see it, from now on, the right place to go to read the syntax is "The JSON Data Interchange Format", aka ECMA-404.

-- 
( Jorge )();