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
parsing.


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
> 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


More information about the es-discuss mailing list