Carsten Bormann (2013-12-08T15:26:57.000Z)
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.