[Bug 29890] New: [SER31] Arrays in sequence normalization

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

            Bug ID: 29890
           Summary: [SER31] Arrays in sequence normalization
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Serialization 3.1
          Assignee: cmsmcq@blackmesatech.com
          Reporter: tim@cbcl.co.uk
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

Consider

document { [1] }

The content expression of a document node constructor is processed in exactly
the same way as an enclosed expression in the content of a direct element
constructor, as described in Step 1e of 3.9.1.3 Content. 

In XQ31 3.9.1.3 Content, point 1.e.i. we read:

"Each array returned by the enclosed expression is flattened by calling the
function array:flatten() before the steps that follow."

So this is equivalent to 

document { 1 }

which can be serialized.

Now compare with 

[1]

In SER31, 2 Sequence Normalization, we read:

"Where the process of converting the input sequence to a normalized sequence
indicates that a value MUST be cast to xs:string, that operation is defined in
Section 19.1.1 Casting to xs:string and xs:untypedAtomic FO31 of [XQuery and
XPath Functions and Operators 3.1]. Where a step in the sequence normalization
process indicates that a node should be copied, the copy is performed in the
same way as an XSLT xsl:copy-of instruction that has a validation attribute
whose value is preserve and has a select attribute whose effective value is the
node, as described in Section 11.9.2 Deep Copy XT30 of [XSL Transformations
(XSLT) Version 3.0], or equivalently in the same way as an XQuery content
expression as described in Step 1e of Section 3.9.1.3 Content XQ31 of [XQuery
3.1: An XML Query Language], where the construction mode is preserve."

This refers to Step 1e, but this is only invoked when copying nodes, not
function items.

So it would appear that

[1]

cannot be serialized, because the array flattening doesn't occur.

If I'm correct, I think this marks the first time that serialization of

document { E }

and

E

behave differently under serialization (other than in error code).

Was this intentional?

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

Received on Monday, 3 October 2016 09:55:17 UTC