This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
1. The handling of quotation marks is covered twice in the string escaping rules: * [...], and any occurrence of quotation mark (") is replaced by \" * [...] any occurrence of quotation mark, backspace [...] The first rule can probably be dropped? I cannot find it in the XSLT spec. neither. 2. FOJS0007 is to be raised if \u is "not followed by four hexadecimal digits (that is [0-9A-F]{4})". Maybe a-f (lower case) should be allowed as well?
I'm finding the rules quite hard to decipher, and I think we can achieve greater clarity by refactoring them as follows: (1) If the attribute escaped="true" is present for a string value, or escaped-key="true" for a key value, then: (1.a) any valid JSON escape sequence present in the string is copied unchanged to the output, (1.b) any invalid JSON escape sequence results in a dynamic error [err:FOJS0007]. (1.c) any unescaped occurrence of quotation mark, backspace, form-feed, newline, carriage return, or tab is replaced by \", \b, \f, \n, \r, or \t respectively, (1.d) any other codepoint in the range 1-31 or 127-159 is replaced by an escape in the form \uHHHH where HHHH is the upper-case hexadecimal representation of the codepoint value. (2) Otherwise (that is, in the absence of the attribute escaped="true" for a string value, or escaped-key="true" for a key value): (2.a) any occurrence of backslash (\) is replaced by \\ (2.b) any occurrence of quotation mark, backspace, form-feed, newline, carriage return, or tab is replaced by \", \b, \f, \n, \r, or \t respectively, (2.c) any other codepoint in the range 1-31 or 127-159 is replaced by an escape in the form \uHHHH where HHHH is the upper-case hexadecimal representation of the codepoint value. I agree that we should allow lower-case A-F in an escape sequence. At one time I was under the impression JSON did not allow this, but this was because I overlooked an obscure clause in RFC4234 whose effect is that the ABNF "A"|"B"|"C" doesn't mean what you think it does.
Changed the title, the question of allowing lower-case a-f is not purely editorial.
The change was accepted and has been applied.
(just clearing the still-open needinfo request of this bug, and transitioning it to "closed" status)