The JSON RFC, by including the escape clause "A JSON parser MAY accept non-JSON forms or extensions", admits non-validating parsers. The table at <http://code.google.com/p/json-sans-eval/> gives us some good terminology. The reason we need JSON to be provided by platforms rather than libraries is that we desire JSON parsers that are simultaneously fast, secure, and validating. Unfortunately, it also specifies only (<object> | <array>) as a valid start symbol for parsing.
On Wed, Jun 3, 2009 at 12:59 PM, Douglas Crockford <[email protected]> wrote: >> 2) Do we want to permit conforming implementations to extend the JSON >> grammar that they recognize? > > No. An implementation has the license to support other formats (such as an > XML object or a SuperJSON object). But the JSON object should recognize only > the JSON forms described by ES5. There should be no Chapter 16 squishiness > here. Crock, is your position that ES5 should specify a validating JSON parse exactly equivalent to the parse specified in the RFC (i.e., waiving the escape clause), but with JSON <value> as the start symbol? If so, then I agree. Are there *any* other differences between the RFC and ES5 besides the start symbol and the RFC's escape clause? If so, can we repair all of them? Has anyone tested the annoying \u2028 and \u2029 issue on current implementations? I'd guess there are currently bugs here as well. -- Cheers, --MarkM _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
