This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I was reading the latest working draft of XSLT 2.0 at http://www.w3.org/TR/xslt20/ , and I noticed an inconsistent description. Section 1.1 says "A transformation expressed in XSLT describes rules for transforming zero or more source trees into zero or more result trees" . Please note the words zero or more.. Is it right to say, if we are using "unparsed-text ($href as xs:string?) as xs:string?" function to parse a text file(which is not a XML file) (and there is no source XML at all as input to transformation) , then there are zero source trees ? Are there any other circumstances when there can be zero source trees? And under what circumstances, we can have zero result trees? Then later in section 2.1 (Terminology) , it is written .. "The software responsible for transforming source trees into result trees using an XSLT stylesheet is referred to as the processor" I feel, the wordings of "definition of a XSLT processor" should reflect the fact, that the XSLT 2.0 processor transforms any text input to any text output (now we may have zero source trees!). My point is quite trivial.. If found appropriate, you may change the wordings of "definition of a XSLT processor" .. Regards, Mukul
It's certainly possible to have zero source trees: consider the stylesheet containing the single template rule <xsl:template name="main">2</xsl:template> invoked without specifying a principal source document. Zero result trees is a bit more questionable. If we change the above template to <xsl:template name="main"/> is there a result tree or not? Section 2.1 is a little ambiguous on this, it says "a final result tree may also be created implicitly by the initial template in the absence of an xsl:result-document instruction". This seems to be saying that the above "may" create a final result tree. In fact, this question isn't purely academic: in earlier releases the above would cause Saxon to overwrite the output file with an empty file, whereas in the current release the output file is untouched (because Saxon doesn't open the output file until it has something to write to it). The phrase that appears in the definition of "XSLT Processor" in 2.1 "source trees into result trees" is deliberately unspecific about how many trees there are, and I don't think one could get any more general than this. I don't feel a strong need to change the other phrase ("zero or more") either. I do think we possibly need a bit more clarity about the circumstances in which a result tree is constructed implicitly in the absence of xsl:result-document, for example does <xsl:template match="/"> <xsl:result-document/> </xsl:template> create 0, 1, or 2 result trees? Michael Kay (personal response)
Discussion of this on 12 May 2005 led to questions about whether an empty result tree should be serialized or not. Left open for the moment.
A progress report and some further thoughts: The XSL WG discussed this on 12 May, without coming to a firm conclusion. We leaned to the view that the definition itself doesn't need changing - you can't try to say everything that can said about an XSLT processor in the definition. We did think there was a need to clarify under what circumstances empty result trees (trees consisting of a document node only) get created, especially in the case of the implicitly-created result tree. My own thinking on this (after the meeting) is that an explicitly-created final result tree (using xsl:result-document) should be output and serialized even if it is empty; but that the implicitly-created result tree that's created in the absense of xsl:result-document should not be output (sent to the serializer, etc) if it is empty, that is, if the document node has no child nodes. This means that it is indeed possible for the transformation to produce zero result trees. Such a transformation can in fact be useful: its purpose might be to validate the source document, so that the only output is a success/failure outcome and possibly some messages. Michael Kay
Thank you for updating about this topic. I am happy, that this is considered significant, and some discussion is going on.. I now feel, that the definition is right. For e.g., at other place, XSLT 2.0 spec says(Section 2.4) "evaluating the sequence constructor of the initial template as described in 5.7 Sequence Constructors. If the result is a non-empty sequence ...". So if there is a empty sequence, the definition still applies! So the present defition of XSLT processor is also right.. The reasoning I (had/am) (posted/posting), are my random thoughts.. Regards, Mukul
A further progress report following XSL WG meetings this week: (a) we decided that a transformation always produces at least one result tree. Contrary to what's stated in a couple of places at the moment, if the initial template returns an empty sequence and if xsl:result-document has not been called, then an empty result tree should be produced (in practice, if you are serializing, the output destination should be overwritten with an empty file). (b) we realized that there's a problem with the current text if the initial template has an "as" attribute, for example if it is: <xsl:template match="xs:integer+"> <xsl:sequence select="1 to 5"/> </xsl:template> The current rules say this is equivalent to <xsl:template match="xs:integer+"> <xsl:result-document> <xsl:sequence select="1 to 5"/> </xsl:result-document> </xsl:template> which would give a type error; but that's problematic since we don't know in advance which template will be the initial entry template. (c) we also realized that there's nothing in the spec currently which says whether or not an implementation is allowed to provide alternative processing models for running the code in a stylesheet, for example by calling an xsl:function directly from the API. So we're leaving the bug open for the moment as our placeholder for sorting out these issues with the processing model. Michael Kay
Your comment led the working group to a re-examination of the exact details of what an XSLT processor does under various circumstances, which continued over a number of meetings. We have now established that: (a) there is always at least one result tree. (b) an implicit result tree is created if either of the following conditions is true: (i) the result of evaluating the initial template is a non-empty sequence, or (ii) no xsl:result-document instruction has been evaluated. If neither of these conditions is true, for example, if the initial template is <xsl:template match="/"> <xsl:result-document validation="strict" href=""> <a/> </xsl:result-document> </xsl:template> then no implicit result tree is produced: that is, the transformation produces one result tree, not two. (c) if the initial template has an "as" attribute, the type checking is applied to the sequence produced by the initial template *before* wrapping this result in a document node (the current text would imply that it is wrapped before type checking). The Working Group also discussed whether there might be other ways of invoking a stylesheet, for example by allowing applications to make direct calls to functions defined using <xsl:function>. In this case there would be no result tree produced, and the result might be, for example, a sequence of three integers, or a single boolean, or a set of nodes in the source tree. We decided that there was nothing in the spec to rule out an implementation providing such a mode of evaluation but that it was outside the scope and definition of an "XSLT Processor" as described in the specification. We think we have now bottomed this subject out and thank you for triggering this review. If you are content with the resolution, please mark the bug as closed.