- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Dec 2014 15:42:39 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27498 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 error. 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 item-separator. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 3 December 2014 15:42:41 UTC