This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec in §2.3.6.1 has some inconsistencies and inaccuracies in the way it describes the functioning of build-tree and item-separator (highlighted in a Saxon bug report from Max Toro). By and large what we have in the spec is consistent with the decisions recorded against bug #29431. However: (A) A Note in section 26 states: "Note: The item-separator attribute has no effect if the sequence being serialized contains only one item, which will always be the case if the effective value of build-tree is yes." This Note is incorrect. When the effective value of build-tree is yes, the tree is built using the "sequence normalization" process described in the serialization spec, and this process takes account of the item-separator attribute. For example if the raw result is a sequence of integers 1 to 5, and the item-separator is "|", then the result of sequence normalization is a document node containing a single text node child with the string value "1|2|3|4|5". (B) The first paragraph of §2.3.6.1 starts "If a result tree is to be constructed from the raw result, then this is done by applying the rules for the process of sequence normalization..." and ends. "In particular, sequence normalization is carried out regardless of any method attribute in the unnamed output definition." This last sentence is misleading. I think the intended reading is "the way in which sequence normalization is carried out does not depend on the chosen serialization method". However, the decision to carry out sequence normalization does depend on the chosen serialization method, to the extent that the method establishes a default for the build-tree property.
There is another related issue concerned with conformance to the optional Serialization Feature. The conformance rules in §27.3 say "A processor that claims conformance with the serialization feature must support the conversion of a final result tree to a sequence of octets following the rules defined in 26 Serialization.]" Now, a "final result tree" is the output of the sequence normalization process. I think it is therefore intended that processors must support construction of a final result tree using the sequence normalization process whether or not they implement the Serialization Feature. But should such a processor take account of the item-separator attribute? The spec says A processor that does not claim conformance with the serialization feature must not signal an error merely because the stylesheet contains xsl:output or xsl:character-map declarations, or serialization attributes on the xsl:result-document instruction. Such a processor MAY check that these declarations and attributes have valid values, but is not required to do so. Apart from optional validation, these declarations SHOULD be ignored. We could go either way on this. We would get better interoperability if a processor that does not support serialization delivers the same result as a processor that does support serialization but happens not to be serializing the result on a particular occasion. That means that such processors SHOULD take account of item-separator when performing sequence normalization.
It is permitted to request <xsl:result-document build-tree="no" method="xml"> But it's not 100% clear what this means. Serialization method="xml" is defined in the Serialization spec, and it has sequence normalization as a necessary first step. I think the only workable interpretation is that if you are serializing, then you must use the XML method, and the XML method necessarily performs sequence normalization, so the build-tree attribute is ignored. But the processor may decide (or be instructed) not to perform serialization, and in this case the build-tree attribute determines whether the result of the xsl:result-document instruction is delivered in raw form or as a document node produced by sequence normalization. Even then, tbe build-tree attribute may be overridden by API provisions (and in Saxon the decision whether to do sequence normalization is entirely determined by the invocation API, so the build-tree attribute has no effect).
A proposed erratum E14 was published on 13 Feb 2019, HTML version: https://htmlpreview.github.io/?https://github.com/w3c/qtspecs/blob/master/errata/xslt-30/html/xslt-30-errata.html#E14 (I have yet to study this proposal and the comments below)