This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When the adaptive serialization method encounters a sequence of length > 1 in a map or array, the rule says: A sequence of length greater than one in the data model instance will be serialized using the Adaptive output method rather than raising a serialization error [err:SERE0023]. If we assume ~ as item separator, this means that if we have the map map { "a": "b" } it is serialized as {"a":"b"} but the map map { "a": ("b", "c") } is serialized as {"a":b~c} Two problems: (a) the difference between the two cases is pretty weird, and (b) the serializer needs to lookahead before outputting the first item in the sequence. I would suggest an alternative: serialize second and subsequent items in the sequence using the same rules as the first item, separating them with the item-separator. This would give {"a":"b"~"c"}
More generally, it's hard to see the logic (and in some cases to decipher the rules) as to when quotes are used by the adaptive output method, especially within the values of maps and arrays. For example, because it inherits the rules from the JSON method, an element is output in quotes: [ "<a/>" ] using JSON escaping for nested quotes: [ "<a class=\"para\"/>" ] But it's not clear whether quotes are used for functions: <quote> A function item is serialized to the representation "function name#A" </quote> but the test cases suggest that the quotes here are not intended to be part of the target representation. Thinking about this overall, I think we've ended up with a very muddled mix of XPath and JSON syntax. I think it would be much better if we targeted something close to XPath syntax, perhaps as follows: The outermost sequence is serialized by serializing each item, as described below, separated by the chosen item separator. Atomic values: values of type xs:string, xs:decimal, and xs:double are output as XPath literals, for example "London", 1.23, 1.5e0. Values of type xs:boolean are output as "true()" or "false()". Values of type xs:untypedAtomic are output as string literals, for example "London". Values of other primitive types are output using the syntax of a constructor function with a string literal argument, for example xs:date("2015-07-14"). Nodes: as now. Maps: output as map{key=value, ...} where key is an atomic value as above, and value is described below. Arrays: output as [value, value, ...] where value is as described below. Functions: as now. Values within maps and arrays: In general, these are output as a sequence of items, surrounded by parentheses and separated by ",". The parentheses are optional in the case of a sequence of length 1. (This allows streaming serializers to output the opening "(" without knowing the length of the sequence). The chosen item-separator is NOT used. Examples: Query: //para Result: <para>One para</para> <para>Para two.</para> Query: count(//para) Result: 22 Query: current-date() Result: xs:date("2015-07-14-05:00") Query: avg((//para)!string-length()) Result: 33.2e0 Query: (//para)!(position()||": "||title) Result "1: Introduction" "2: Early Life" "3: Nemesis" Query: //para/@* Result: class="para" id="p123" class="para" id="p456" Query: array { 1 to 5 } Result: [1,2,3,4,5] or [(1),(2),(3),(4),(5)] Query: array { //para } Result: [<para>One para</para>,<para>Para two</para>] or [(<para>One para</para>),(<para>Para two</para>)] Query: map:merge( //para ! map:entry(position(), .) ) Result: map{1:<para>One para</para>,2:<para>Para two</para>} or map{1:(<para>One para</para>),2:(<para>Para two</para>)}
DECISION: Adopt MKay's proposal for changes to the "Adaptive" serialization method from the following email, bullet 3: https://lists.w3.org/Archives/Member/w3c-xsl-query/2015Jul/0026.html