RE: [xsl] Why XTRE1500: Cannot read a document that was written during the same transformation ?

Subject: RE: [xsl] Why XTRE1500: Cannot read a document that was written during the same transformation ?
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Wed, 30 Jan 2008 20:55:58 -0000
> But I do not understand why *XTRE1480* is an error!

I assume you mean XTDE1480: using xsl:result-document in temporary output

> 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.


<xsl:variable name="temp" as="item()*">
  <xsl:sequence select="1"/>
  <xsl:sequence select="2"/>
  <xsl:result-document href="output.xml">

<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

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

Current Thread