28663 2015-05-20 15:21:48 +0000 [FO31] Escaping rules in fn:xml-to-json 2015-10-16 18:34:10 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.1 Candidate Recommendation PC Windows NT CLOSED FIXED P2 normal --- 1 christian.gruen mike abel.braaksma public-qt-comments public-qt-comments oldest_to_newest 120386 0 christian.gruen 2015-05-20 15:21:48 +0000 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? 120597 1 mike 2015-05-29 10:00:59 +0000 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. 120599 2 mike 2015-05-29 10:15:15 +0000 Changed the title, the question of allowing lower-case a-f is not purely editorial. 120665 3 mike 2015-06-02 20:19:57 +0000 The change was accepted and has been applied. 123744 4 abel.braaksma 2015-10-16 18:34:10 +0000 (just clearing the still-open needinfo request of this bug, and transitioning it to "closed" status)