This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 10, Character Maps, needs to be updated to account for JSON "Character maps allow a specific character appearing in a text or attribute node in the instance of the data ..." "... that actually appear in a text or attribute node in the instance ..." "... in the use-character-maps in text nodes and attribute values are replaced ..." This text now applies to strings as well as nodes. -- In section 4, phases of serialization, bullet 3, I believe the intent is that character expansion occurs for values that will be output as JSON strings (not just strings). For example, if the output contains a QName, this won't be subject to character expansion yet it will still be output as a JSON string. Is this really the intent?
Also, I think the order of nested serialization wrt character expansion needs to be clear. For example: declare option output:method "json"; text { "
" } Does this produce: " " Or "\u000D" (I have added this as a test in XQTS) I assume the intent is that: (1) The original node is converted to a string using "xml" serialization (2) Character expansion rules of "json" apply to the resulting string (i.e. "json" character expansion isn't applied to the text node)
The QT WGs discussed this issue on their joint call today, and agreed that the state of affairs described in the first paragraph appears to be a problem we should fix; the editors were so instructed. The answer to the question ending the second paragraph is (as far as we can tell) "yes". The analysis is essentially that any attempt to serialize QNames to JSON is almost certainly either (a) headed for disappointment at some stage, which we cannot prevent, or (b) doing something very clever, which we cannot predict. Other analyses of the situation are possible, but there was not consensus today for changing the spec in this point. Accordingly, I'm marking this bug as resolved. Josh, please review the resolution and indicate your assent or dissent by closing or reopening the bug as appropriate. If we don't hear from you in the next two weeks, the WGs will assume you assent.