JSON parser grammar
Mark S. Miller
erights at google.com
Wed Jun 3 13:50:32 PDT 2009
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
On Wed, Jun 3, 2009 at 12:59 PM, Douglas Crockford
<douglas at crockford.com> 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
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
Has anyone tested the annoying \u2028 and \u2029 issue on current
implementations? I'd guess there are currently bugs here as well.
More information about the es-discuss