But I do not understand why *XTRE1480* is an error!
I assume you mean XTDE1480: using xsl:result-document in temporary output
state.
And the reason given by the norm is not very convincing, it
just says that it is: "to ensure that the results are fully
interoperable even when processors optimize the sequence in
which instructions are evaluated".
I know it's not the role of W3C to give more details, but if
you could give me some convincing example of
over-optimization in the case where XTRE1480 happens, I would
less regret to have had to write a cumbersome workaround for that.
Consider
<xsl:variable name="temp" as="item()*">
<xsl:sequence select="1"/>
<xsl:sequence select="2"/>
<xsl:result-document href="output.xml">
<out/>
</xsl:result-document>
</xsl:variable>
<xsl:value-of select="$temp[2]"/>
Does the output get written or not?
(The point being that implementations are only required to evaluate
variables - or any other subexpressions - to the extent needed to determine
their result. Many implementations using pipelining and lazy evaluation will
be able to compute $temp[2] without looking beyond the second item in the
sequence)
If the third instruction were xsl:message rather than xsl:result-document,
it would be implementation-defined whether the message gets written out. If
it were <xsl:sequence select="error()"/>, it would be implementation-defined
whether the error gets thrown. The WG didn't want it to be
implementation-defined whether final result documents get written or not.
At one time the WG tried to model this a different way, and you might find
it helpful. In this model, xsl:result-document produces a
"document-reference" node that is present on the main result tree, linking
to the document node of the secondary result tree. So the output of the
stylesheet is in effect a single tree, in which secondary documents are
linked as descendants into the primary tree; it's only the serializer that
splits this uber-tree into separate documents. The advantage of this model
is that there are strictly no side-effects. The disadvantage was that it
meant putting something rather artificial into the XDM data model, raising
questions about how these document-reference nodes would be accessible to
path expressions and so on. We went for the notion of "temporary output
state" because it didn't involve tweaking the data model in that way.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--