[Bug 27498] New: [ser 3.1]Unfailing serialization


            Bug ID: 27498
           Summary: [ser 3.1]Unfailing serialization
           Product: XPath / XQuery / XSLT
           Version: Last Call 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

When a user enters a query at a command line or other "ad-hoc" interface, they
expect to see an answer displayed. They don't expect to be told that the query
succeeded, but the results can't be displayed because there was a serialization

This wasn't a problem in the past because in nearly all cases, if the query
succeeded, then serialization would also succeed (one of the notable exceptions
was a query that returns attribute nodes).

But with the introduction of maps and arrays, we're seeing lots of ad-hoc
queries that produce serialization errors. In fact, we're moving towards
displaying the results of queries using our own ad-hoc serialization that
doesn't correspond to anything in the serialization spec. The logic is
something like: display nodes using XML serialization, display maps and arrays
using JSON serialization.

I feel uncomfortable that we are finding we need to do serialization in a way
that isn't covered by the spec. Anyone else feel the same?

Especially as the item-separator property was apparently invented for this kind
of use case.

I think there's a need for some kind of "adaptive" serialization where a
sequence is serialized by choosing an appropriate serialization method for each
item based on what kind of item it is, and then separating the items using

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

Received on Wednesday, 3 December 2014 15:42:41 UTC