Carsten Bormann (2013-12-08T15:26:57.000Z)
Hi Allen,

here are some replies to your messages that I promised.  I opted not to
use line-by-line responses; I hope they are easier to read this way.
Two technical, and two more general points.

* Processing model

You are presenting a processing model that is based on a generic
parser that creates an AST and then application-specific
post-processing.  This is pretty much how XML worked.

One of the major advances of JSON was that it has a data model (even
if it is somewhat vaguely specified — implementers were still quick in
picking it up).  JSON implementations typically go right from the
characters to a representation of that data model that is appropriate
for the platform, and encoders typically go all the way back in one
step.  Interoperability happens as a result of this processing.

That's a major reason why it is so important to think about JSON in
terms of its data model.  The IETF JSON WG has elected not to flesh
out the model any more for 4627bis than it is in RFC 4627 (which I
personally don't agree with, but it would have been more hard work).
Dismantling what is there in the way of a data model, and thus falling
back into an XML mindset, would be a major regression, though.

* Description techniques

You are right that programming language designers have been used to
two-level grammars (scanner/parser) for a long time.  One thing that
RFC 4627 got right was not doing this, but using the single-level
ABNF.  (Technically, there still is an UTF-8 decoder below the ABNF,
but that is a rather well-understood, separable machine.)  JSON is
simple enough to enable single-level description, and RFC 5234 ABNF
provides a rigorous yet understandable way to do this.  There are
tools that operate on that ABNF and produce useful results, because it
has a defined meaning.

Let me be very frank here, because I get the impression that previous
statements about this were too diplomatic to be clear.

There is no way on earth that anyone can argue that the description of
the JSON syntax in ECMA-404 is in any way superior to that in RFC
4627.  By a large margin.  This is not about possibly finding bugs in
the hodge-podge that ECMA-404 is; thank you for offering to do ECMA's
work here, but I'm not biting.  This is about making sure from a start
that the spec is right.  Making 4627bis reference ECMA-404 would be a
major regression.  There is no reason for incurring this regression
seven years after it already was done right.  The IETF isn't known for
doing things that are unjustifiable on a technical level.

* Stewardship

You mention that there is significant programming language expertise
in TC39.  I couldn't agree more (actually, the previous sentence is a
wild understatement), and I can say that I have been using ECMA-262
(ES3 is the last version with which I have significant experience) as
a model for programming language standards.

My point was not at all about lack of experience, it is about
attention.  By its nature, TC39's work on JSON will always focus on
the narrower needs of JavaScript.  That makes TC39 less qualified for
the stewardship of a standard that transcends language barriers than
one might like to admit.  I'm not going to illustrate this point
further; there is ample illustration in the mailing list archives.

* Way forward

As always, only the chairs can speak for the JSON WG, and even they
need to confirm any needed consensus in the WG beforehand.  But I
think I can say that we are still only guessing what TC39 is trying to
achieve with the sudden creation of ECMA-404.  I think we need to have
a frank discussion about the objectives of further work on JSON.  The
JSON WG has a charter that defines its objectives, which is focusing
on stability and interoperability.  I'd like to understand TC39's
objectives with respect to JSON, so we can find out whether there is
common ground or not.

Grüße, Carsten
domenic at domenicdenicola.com (2013-12-10T00:56:57.802Z)
here are some replies to your messages that I promised.  I opted not to
use line-by-line responses; I hope they are easier to read this way.
Two technical, and two more general points.

# Processing model

You are presenting a processing model that is based on a generic
parser that creates an AST and then application-specific
post-processing.  This is pretty much how XML worked.

One of the major advances of JSON was that it has a data model (even
if it is somewhat vaguely specified — implementers were still quick in
picking it up).  JSON implementations typically go right from the
characters to a representation of that data model that is appropriate
for the platform, and encoders typically go all the way back in one
step.  Interoperability happens as a result of this processing.

That's a major reason why it is so important to think about JSON in
terms of its data model.  The IETF JSON WG has elected not to flesh
out the model any more for 4627bis than it is in RFC 4627 (which I
personally don't agree with, but it would have been more hard work).
Dismantling what is there in the way of a data model, and thus falling
back into an XML mindset, would be a major regression, though.

# Description techniques

You are right that programming language designers have been used to
two-level grammars (scanner/parser) for a long time.  One thing that
RFC 4627 got right was not doing this, but using the single-level
ABNF.  (Technically, there still is an UTF-8 decoder below the ABNF,
but that is a rather well-understood, separable machine.)  JSON is
simple enough to enable single-level description, and RFC 5234 ABNF
provides a rigorous yet understandable way to do this.  There are
tools that operate on that ABNF and produce useful results, because it
has a defined meaning.

Let me be very frank here, because I get the impression that previous
statements about this were too diplomatic to be clear.

There is no way on earth that anyone can argue that the description of
the JSON syntax in ECMA-404 is in any way superior to that in RFC 4627.  By a large margin.  This is not about possibly finding bugs in
the hodge-podge that ECMA-404 is; thank you for offering to do ECMA's
work here, but I'm not biting.  This is about making sure from a start
that the spec is right.  Making 4627bis reference ECMA-404 would be a
major regression.  There is no reason for incurring this regression
seven years after it already was done right.  The IETF isn't known for
doing things that are unjustifiable on a technical level.

# Stewardship

You mention that there is significant programming language expertise
in TC39.  I couldn't agree more (actually, the previous sentence is a
wild understatement), and I can say that I have been using ECMA-262
(ES3 is the last version with which I have significant experience) as
a model for programming language standards.

My point was not at all about lack of experience, it is about
attention.  By its nature, TC39's work on JSON will always focus on
the narrower needs of JavaScript.  That makes TC39 less qualified for
the stewardship of a standard that transcends language barriers than
one might like to admit.  I'm not going to illustrate this point
further; there is ample illustration in the mailing list archives.

# Way forward

As always, only the chairs can speak for the JSON WG, and even they
need to confirm any needed consensus in the WG beforehand.  But I
think I can say that we are still only guessing what TC39 is trying to
achieve with the sudden creation of ECMA-404.  I think we need to have
a frank discussion about the objectives of further work on JSON.  The
JSON WG has a charter that defines its objectives, which is focusing
on stability and interoperability.  I'd like to understand TC39's
objectives with respect to JSON, so we can find out whether there is
common ground or not.