On Nov 13, 2013, at 1:27 PM, Paul Hoffman wrote: > <no hat> > > On Nov 13, 2013, at 12:24 PM, Joe Hildebrand (jhildebr) <jhildebr@xxxxxxxxx> wrote: > >> We would also need to change section 8.1 according to the mechanism that >> was previously proposed: >> >> 00 00 00 xx UTF-32BE >> 00 xx ?? xx UTF-16BE >> xx 00 00 00 UTF-32LE >> xx 00 xx ?? UTF-16LE >> xx xx ?? ?? UTF-8 >> >> in order to account for strings at the top level whose first character has >> a codepoint greater than 127. > > A string at the top level of a JSON text still needs to start with an ASCII " character, so the logic is still fine, I believe. > > Carsten's point about whitespace is more problematic. Does the ECMA-404 definition of a JSON text allow it to start with one (or more) whitespace characters? The text in that document says: > . . . > A JSON text is a sequence of tokens formed from Unicode code points that conforms to the JSON value grammar. The set of tokens includes six structural tokens, strings, numbers, and three literal name tokens. > . . . > Insignificant whitespace is allowed before or after any token. > . . . > > It would be nice if ECMA-404 was clearer on this, given that the racetrack illustrations show everything other than the whitespace. In specific, it would be good to know whether or not the racetrack for "value" in Section 5 is meant to have optional whitespace at the left and right to match the above text. If TC39 could say for certain on that, it would be useful to the community. Yes, leading white space is allowed: "The set of tokens includes the six structural tokens, *strings*, *numbers*, ..." (emphasis added) "Insignificant whitespace is allowed before or after any token" The elements matched by the value production are all tokens (or productions that begin and end with a token) so whitespace can occur to the left or right of any value Allen