This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was first discussed by email, see:https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Oct/0031.html (member only) Copying the email contents for convenience here: <quote> The item-separator serialization parameter defined in [XSLT and XQuery Serialization] is not available in xsl:output; it is not applicable, because the sequence that is serialized by XSLT is always a singleton document node. Formally therefore, the serializer is always invoked passing an empty string as the value of this parameter. </quote> Under 2.6 we say this: <quote> An XSLT stylesheet describes a process that constructs a set of final result trees from a set of source trees. </quote> But earlier in 2.4 we say: <quote> The process of generating a result tree from the raw result of the initial template may be replaced with the very similar sequence normalization process described in 25 Serialization. In the latter case the serialization parameter item-separator may be used to separate items in the raw result with a string other than space </quote> In 2.3.3, 2.3.4 and 2.3.5 we only talk about "raw result" for the three types of invocation. In 2.3.6 we offer two optional stages of post-processing: (1) result tree construction (optional) and (2) serialization (optional). The problem with the above is that: 1) under xsl:result-document and xsl:output we say that @item-separator has no effect 2) under 2.6 we say that a transformation always creates a result tree 3) under 2.3.6 we say that a transformation creates a raw result and that you do not need to create a result tree 4) also under 2.3.6 we say that you can use @item-separator to separate the items in the raw result. I'm not sure what was discussed about @item-separator, but I think we should be clear about it: either it has no effect, or it can be used similar to xsl:value-of/@separator (my preference). I'm not sure what the spec currently tries to say. ---------------------------------------------------------------------- Addendum: during WG telcon of Oct 23, it was recognized that item-separator should be supported and should separate items when serializing, typically similar to the way xsl:value-of/@separator works. The text should be updated to reflect this.
Also: Remember also to check J.1, which mentions the inapplicability of item-separator as a chnage since 2.0.
<quote setion="25"> The item-separator serialization parameter defined in [XSLT and XQuery Serialization] is not available in xsl:output... </quote> This paragraph is clearly obsolete, because we allow xsl:output/@item-separator. We should replace this paragraph with an explanation of the effect of the attribute. As explained in 2.3.6, the attribute has no effect if the transformation result is processed using result tree construction followed by serialization (because there is then only one item), but it does have effect if serialization is used without result tree construction. <quote section="2.6"> An XSLT stylesheet describes a process that constructs a set of final result trees from a set of source trees. </quote> This section needs updating because the output is no longer always a set of final result trees; it needs to recognize the possibility of producing "raw output" (and optionally, serializing the raw output without first building a tree). <quote section="24.1"> The item-separator serialization parameter defined in [XSLT and XQuery Serialization] is not available in xsl:result-document; it is not applicable, because the sequence that is serialized by XSLT is always a singleton document node. </quote> We allow item-separator on xsl:result-document, but I'm not sure it has any effect. Currently we say that xsl:result-document always creates a tree and optionally serializes it. If the thing being serialized is always a document node, then it is a single item, so the item separator can have no effect. So we should probably remove the possibility of specifying xsl:result-document/@item-separator, unless we want to allow xsl:result-document to produce "raw" output. Serialization 3.1 defines a JSON serialization method, and although this makes no use of item-separator, if a transformation is going to be able to write multiple JSON output files then we need to allow xsl:result-document to produce (and serialize) raw sequences without constructing a tree. Perhaps xsl:result-document should have an attribute such as build-tree=yes|no, and then item-separator makes sense if build-tree="no". For example, <xsl:result-document href="out.txt" method="text" build-tree="no" item=separator="|"> <xsl:sequence select= 1 to 5"/> </xsl:result-document> would produce the output file 1|2|3|4|5
Maybe a silly comment, but would item-separator kick in with CVTs? I.e.: <xsl:result-document item-separator=" "> <xsl:text expand-text="yes">{1 to 5}</xsl:text> </xsl:result-document> Would the output be: 1 2 3 4 5 or: 12345 (without trying to find it in the spec, I have to confess I am not even sure whether a CVT works the same as xsl:value-of, where the default separator is " " (space))
(In reply to Abel Braaksma from comment #3) > Maybe a silly comment, but would item-separator kick in with CVTs? I.e.: > > <xsl:result-document item-separator=" "> > <xsl:text expand-text="yes">{1 to 5}</xsl:text> > </xsl:result-document> > > Would the output be: 1 2 3 4 5 > or: 12345 > > (without trying to find it in the spec, I have to confess I am not even sure > whether a CVT works the same as xsl:value-of, where the default separator is > " " (space)) A CVT is evaluated to produce a text node, under the rules for constructing simple content. These rules cause atomic values to be separated by spaces. The item-separator property is not relevant to this case, because by the time serialization happens, there is only one text node, therefore one item, therefore no need for a separator.
I have made the first change in comment 2 (removing the statement that item-separator is not allowed), but the other changes need WG discussion. The key question is, should xsl:result-document always construct a document node? If it does, then we cannot produce secondary results in JSON format. I propose that xsl:result-document should produce a document node only if the output method is xml, html, xhtml, or text. If the output method is anything else, it is sent in raw form to the serializer, which can do what it likes with it. Of course in 3.0 the only other method allowed is user-defined serialization method, but we can add a note that JSON is coming along. This means that item-separator makes sense on xsl:result-document, to support serialization methods other than these four.
The WG agreed in principle (subject to a detailed proposal) to add a new attribute to xsl:output and xsl:result-document to indicate whether the raw output should be built into a tree prior to serialization.
The changes put forward by the editor were accepted, with a couple of minor observations which have been implemented.