- From: Paul Hoffman <paul.hoffman@vpnc.org>
- Date: Wed, 13 Nov 2013 13:27:58 -0800
- To: Joe Hildebrand Hildebrand <jhildebr@cisco.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, es-discuss <es-discuss@mozilla.org>, IETF Discussion <ietf@ietf.org>, "www-tag@w3.org" <www-tag@w3.org>, JSON WG <json@ietf.org>
<no hat> On Nov 13, 2013, at 12:24 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> 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. --Paul Hoffman
Received on Wednesday, 13 November 2013 21:28:35 UTC