Here are my views on this.
2) Do we want to permit conforming implementations to extend the JSON grammar that they recognize? This probably could be done by extending the syntax error extension allowance in section 16 to include the JSON grammar. If we allow this then most of the observed variation for the current emerging implementation that we have been talking about would probably be acceptable extensions.
Yes, unless we want to have a confusing proliferation of different JSON method names as we add new data types to the language in the future.
3) If we disallow JSON grammar extensions (for JSON.parse) should we extend the existing grammar with some Postel's Law flexibility?
No, except for things we explicitly discuss and approve here.
Here are the individual cases that I know of to consider: a) Allow strings, numbers, Booleans, and null in addition to objects and arrays as top level JSON text.
Yes.
b) Permit leading zeros on numbers either with or without octal implications.
No.
c) Trailing commas in objects and arrays
No.
d) Holes in arrays, eg [1,,3]
No.
e) Allow some/all control characters to appear unescaped in JSON string literals. Which ones?
Don't care, as long as all of them (except line terminators) are treated alike.
f) Allow single quotes within JSON text as string delimiters
No. Waldemar _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
