JSON parser grammar

Douglas Crockford 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
JSON rules.

 > 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
extra commas.

 > d)  Holes in arrays, eg [1,,3]

No holes.

 > 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

No.


More information about the es-discuss mailing list