[Json] JSON: remove gap between Ecma-404 and IETF draft
On Nov 13, 2013, at 3:51 PM, Joe Hildebrand (jhildebr) wrote:
On 11/13/13 3:47 PM, "John Cowan" <cowan at mercury.ccil.org> wrote:
It's not clear that 404 disallows it, since 404 is defined in terms of characters, and a BOM is not a character but an out-of-band signal.
However, for example, a conforming implementation of the ECMAScript JSON.parse function would reject any string passed to it that starts with a U+FFEF code point because the unquoted occurrence of that code point does not conform to the ECMA-252, 5th Edition or Ecma-404 JSON grammar.
In order to be successfully processed, that code point would have to be stripped from the string prior to calling JSON.parse.
Allen
Agree. However, that signal would be a part of the 4627bis octet stream, so a little interop guidance would likely be useful. Something like:
"Some producers of JSON produce JSON-text that starts with a redundant U+FEFF (ZERO WIDTH NO-BREAK SPACE, previously known as BYTE ORDER MARK) with the ostensible purpose of signaling the encoding of the text to follow. Since JSON has other mechanisms to determine encoding, this is not required. Receiving applications MAY safely ignore this initial character without generating an error. Implementations that do not send U+FEFF are interoperable in the sense that all software implementations which receive the un-prefixed text will not generate parse errors."
Isn't it an interooperbility issue that many receiving applications do not ignore it.
On Nov 13, 2013, at 7:15 PM, Paul Hoffman wrote:
The question was specifically about ECMA-404, not ECMA-252. It would be great to hear from TC39 whether or not ECMA-404 allows or disallows it.
ECMA=nnn is the correct designation for Ecma standards. When speaking about the organization "Ecma" is the usage.
On Nov 14, 2013, at 7:33 AM, John Cowan wrote:
Per contra, ECMA-404 refers only to text(ual content). The BOM is meaningful when transforming byte sequences into code point sequences, but ECMA-404 deals in the latter only. So it is the furthest thing from surprising that it makes no mention of BOMs, and has nothing to say about their use outside text.
Exactly ECMA-404 only defines a textual content format. That was intentional.
On Nov 13, 2013, at 1:27 PM, Paul Hoffman wrote:
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