more JSON spec questions

Allen Wirfs-Brock Allen.Wirfs-Brock at
Thu Aug 27 09:04:01 PDT 2009

>-----Original Message-----
>From: es-discuss-bounces at [mailto:es-discuss-
>bounces at] On Behalf Of Hallvord R. M. Steen
>1) Apparently the grammar still disallows literal tab inside JSONString.
>Implementations that pass this test allow it:
>- from earlier discussions I had the impression that the spec would

The JSON grammar and the RFC has "always" disallowed all control characters (including tabs) from appearing unescaped inside JSONStrings.  This has come up for discussion several times but I believe that we have always gone back to the RFC to guide us.  Can you point to what made you think this was going to change.

>2) The grammar and an existing test in the test suite disallows
>final commas in array input (JSON.parse('[1,]') should apparently throw)
>IE8, Safari 4 and Firefox 3.5 all seem to happily accept it though, as
>does the yet-to-go-public Opera implementation. I'd like some
> from other browser vendors that you consider this a bug and intend to
>it before I push for a fix here because this is the kind of thing that
>might cause compat problems :-o (Guess this is more a question for the
>implementers on the list than for the spec authors.)

The spec. means what it says in this regard and additionally forbids conforming implementations from extending specified JSON grammar for use in JSON.parse (you can, of course, provide a different implementation specific parsing function that uses an extended grammar).

I think I already stated on another thread that Microsoft plans on ultimately bringing our JSON implementation into full conformance with the spec.

>3) Should JSON.parse() without arguments throw? It's not obvious from
>spec as far as I can tell, but it's what most browser implementations

Parse Step 1: "Let JText be ToString(text)".
If parse had no arguments, text will treated as the value undefined and do ToString(undefined) so JText is the string value 'undefined'
step 2. "throw a SyntaxError exception if the JText did not conform to the JSON grammar for the goal symbol JSONText."
The identifier undefined does not reduce to JSONText according to the grammar so a SyntaxError should be thrown.

>4) (Editorial) - spec says "The abstract operation Str(key, holder) has
>access  to
>PropertyList and ReplacerFunction" - the algorithm does not actually use
>PropertyList (very trivial issue, of course)


>5) (Editorial) It's not apparent from the prose description of
>JSON.stringify() that if the replacer argument is an array, it will only
>be applied to objects. I expected to be able to do something like
>JSON.stringify( [0,1,2], [1] ) => '[1]'. Suggest a small clarification,
>perhaps just saying "selecting object keys that will be stringified"
>instead of "selecting the keys that will be stringified"

I replaced "keys" with "object properties" (even though arrays are also objects).  What's a "key" anyway.

In general, the algorithms are normative, not the prose descriptions.

>6) (Editorial) Per the algorithm, passing in a "replacer" array to
>JSON.stringify() will cause it to also stringify dontEnum properties. An
>example would be JSON.stringify( Number, ['MAX_VALUE'] ) including the
>MAX_VALUE property where JSON.stringify(Number) would not. Perhaps
>this in the prose too, not just in the algorithm? Calling it a
>seems it will only narrow down the number of elements that are included,
>not expand it..

An interesting point that I don't recall having been mentioned before.  These isn't any prose that says that only enumerable properties get stringified and steps 5 and 6 of JO are pretty clear about which properties are examined in both the list and no-list cases. Given that (and the late date) I'm disinclined to add a note.


More information about the es-discuss mailing list