I want to bring this discussion around to focus on concrete points that we need
to make decisions on.
1) There is a bug in the ES5 candidate spec. in that it says that:
JSONSourceCharacter ::
SourceCharacter but not U+0000 thru U+001F
This is pretty clearly bogus as it means that tabs and new line characters
cannot occur anywhere in JSON source text (not just string literals). I'll
probably fix it by simply equating JSONSourceCharter to SourceCharacter.
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.
My inclination is to say we should disallow such open-ended extensions. As I
suggest earlier, an implementation can always provide a non-standard extended
parse function if it wants to support an extended grammar.
3) If we disallow JSON grammar extensions (for JSON.parse) should we extend the
existing grammar with some Postel's Law flexibility?
I could accept this for cases where we have some evidence that there are actual
JSON encoders in the wild that violate/extend the JSON grammar in the
identified manner.
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.
The ES5 spec. already has this although it isn't in the RFC. I haven't heard
any suggestions that we remove it.
b) Permit leading zeros on numbers either with or without octal implications.
I'm with Brendan on this, I don't think we should let octal constants into
JSON. I don't have deep problem with leading zeroes for decimal constants but
given the historic octal interpretation within JavaScript it is probably safer
to syntax error than to simply ignore leading zeros.
Does anyone know of any encoders or uses that actually insert leading 0's?
c) Trailing commas in objects and arrays
Are there encoders that do this or are we just anticipating that there might be
manually generated files where this is convenient?
I could go either way on this one but would prefer some supporting evidence
d) Holes in arrays, eg [1,,3]
I don't think we should allow it unless we know there are encoders that
generate it was acceptable to legacy eval based parsers.
e) Allow some/all control characters to appear unescaped in JSON string
literals. Which ones?
Might be plausible. Crock, why did you originally forbid them? Are there
known encoders that pass through such characters without escaping them?
f) Allow single quotes within JSON text as string delimiters
I'm not really suggesting we allow this, but I'm told that at least one major
web site has done this.
Any other possible Postelisms? I have to say, that going through this list I
don't find many of them very compelling.
Votes??
Allen
>-----Original Message-----
>From: Rob Sayre [mailto:[email protected]]
>Sent: Wednesday, June 03, 2009 11:32 AM
>To: Oliver Hunt
>Cc: Allen Wirfs-Brock; Robert Sayre; Mark S.Miller; es-
>[email protected]
>Subject: Re: JSON parser grammar
>
>On 6/3/09 2:25 PM, Oliver Hunt wrote:
>>>>> 2.) trailing commas in objects and arrays are allowed
>>>>> ({"foo":42,"bar":42,})
>>>> V8's JSON implementation also accepts [1,,,2]
>>>
>>> What does it produce? An array with holes, or an array with null
>>> members?
>> An array with holes -- in so far as i can tell V8's json object
>> exactly matches the result of eval(string), just prohibiting arbitrary
>> code execution.
>I don't think we want to live with this. You should never get a
>hole/undefined out of JSON.
>
>- Rob
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
