JSON parser grammar
douglas at crockford.com
Wed Jun 3 12:59:28 PDT 2009
> 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.
> 3) If we disallow JSON grammar extensions (for JSON.parse) should we extend
> the existing grammar with some Postel's Law flexibility?
> a) Allow strings, numbers, Booleans, and null in addition to objects and
> arrays as top level JSON text.
Yes. This turns out to be very useful.
> b) Permit leading zeros on numbers either with or without octal implications.
No. Clearly we don't want octal. Allowing octally forms invites confusion.
> Does anyone know of any encoders or uses that actually insert leading 0's?
I do not know of any. If they did exist, they would be in violation of the
> c) Trailing commas in objects and arrays
This is a hazard for hand coding, just as with object literals. JSON was
intended for machine-to-machine communication, so I prefer to not allow
> d) Holes in arrays, eg [1,,3]
> e) Allow some/all control characters to appear unescaped in JSON string
> literals. Which ones?
No. Keep it simple.
> Are there known encoders that pass through such characters without escaping them?
Not that I know of. Again, would be in violation.
f) Allow single quotes within JSON text as string delimiters
More information about the es-discuss