> 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. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
