[Bug 26784] New: [SER 3.1] Comments on JSON Serialization Method

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26784

            Bug ID: 26784
           Summary: [SER 3.1] Comments on JSON Serialization Method
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Serialization 3.1
          Assignee: cmsmcq@blackmesatech.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

Apologies that this review could have been done months ago; I only just noticed
the spec.

The comment applies to XSLT and XQuery Serialization 3.1 dated 24 April 2014,
mainly section 9.

1. Serializing maps. After converting keys to strings there may be duplicate
keys, e.g. the string "2014-09-11" and the date 2014-09-11 are not equal but
both convert to the same string. What happens?

2. Serializing maps. Should be explicit that the serialization order of entries
is impl-dep.

3. The proposal is that nodes in the input should be atomized. I think it would
generally be more useful if they are serialized (using the XML output method
with default properties plus omit-xml-declaration="yes"). Also note,
atomization of a node does not produce a single atomic value, it produces a
sequence of atomic values.

4. indent: I think we should specify that if indent="no", the serializer must
output no whitepace between tokens (none is required to satisfy the grammar).
Because this could generate very long lines, while indent="yes" might generate
very verbose output, perhaps there's a need for an intermediate option to
insert a newline occasionally to limit the line length?

5. suppress-indentation: I can't see how this is relevant to JSON
serialization.

6. We should specify which characters should be escaped using JSON escape
sequences. Probably only (a) those where escaping is mandatory, e.g. backslash
and double-quotes, plus \n, \t etc; plus any characters that can't be
represented directly in the chosen encoding. (So encoding="us-ascii" forces
escaping of non-ASCII characters).

7. Section 9 (JSON output method) says that the effect of item-separator is
described in section 2 (Sequence Normalization), but section 2 (on my reading)
says that it does not apply to the JSON output method. (An alternative reading
is that sequence normalization is mandatory for all output methods except JSON,
where it is presumably optional...)

8. There seem to be values for which no JSON serialization is defined. For
example, sequences. What is the JSON serialization of (1 to 10)? Is this an
error? I would be inclined to serialize any sequence of length > 1 as an array.

9 Other values that cannot be serialized into legal JSON include INF, NaN, and
function items. These should probably be serialization errors.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 11 September 2014 11:50:31 UTC