W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2015

needinfo requested: [Bug 28663] Editorial: fn:xml-to-json

From: <bugzilla@jessica.w3.org>
Date: Fri, 29 May 2015 10:00:59 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-28663-523-pSJkFVs347@http.www.w3.org/Bugs/Public/>
Michael Kay <mike@saxonica.com> has asked Mailing list for public feedback on
specs from XSL and XML Query WGs <public-qt-comments@w3.org> for needinfo:
Bug 28663: Editorial: fn:xml-to-json
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28663



--- Comment #1 from Michael Kay <mike@saxonica.com> ---
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.
Received on Friday, 29 May 2015 10:01:00 UTC

This archive was generated by hypermail 2.3.1 : Friday, 29 May 2015 10:01:01 UTC