JSON parser grammar

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Mon Jun 8 11:19:33 PDT 2009

Conforming consensus...

I want to make sure that I understand the consensus of last week's discussion on this thread so I can update the spec. accordingly.  Below is the decision points that I sent out last week.  I've annotated it with what I believe was the consensus of the discussion.  Let me know if anybody disagrees that this is actually the consensus conclusions.

There are two new items at the end of the list that came up in the thread.  It's not clear to me whether there was consensus on the final item.

Are there any other points that need to be captured?


>-----Original Message-----
>From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
>bounces at mozilla.org] On Behalf Of Allen Wirfs-Brock
>Sent: Wednesday, June 03, 2009 12:43 PM
>To: Rob Sayre; Oliver Hunt
>Cc: Mark S.Miller; es-discuss at mozilla.org; Douglas Crockford; Robert
>Subject: RE: JSON parser grammar
>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

Do apparent disagreement.  This is just a simple bug fix.

>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

We will require strict conformance with no extensions from the ES5 specificaiton.

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

Yes we keep this extension in the specification 

>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
>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
>Does anyone know of any encoders or uses that actually insert leading

No, no octal and no leading 0 interpretation as decimal

>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


>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


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

Allow JSON.parse to recognize unquote property name.


In addition of code units in the range 0x0000-0x001f JSON.stringify inserts escape sequences into string literals for some or all of the following code units: 
0x007f-0x009f, 0x00ad, 0x0600-0x0604,0x070f,0x17bf,0x17b5,0x200c-0x200f,0x2028-0x202f,0x2060-0x206f,0xfeff,0xfff0-0xffff

Was there any consensus that at least some of these code points should be escapeded?  If show which if not all?

More information about the es5-discuss mailing list