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: Alain <alainb06@xxxxxxx>
Date: Thu, 31 Jan 2008 20:14:58 +0100
> Michael Kay wrote
> I assume you mean XTDE1480: using xsl:result-document in temporary output
> state.

Yes indeed, that's what I meant !

Your explanation is very clear Michael. And I would have preferred the solution the WG
rejected, as it makes thing more symmetric and gets rid of the nasty side effect.
Of course I understand it has other "effects", as it would have modified a foundation:
the XDM Data Model!

I 'm ok with your example with the variables and the lazy evaluations.
I though the "optimisations" could be even harder.


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

<xsl:value-of select="$temp[3]">

The norm says that <xsl:result:document> produces "nothing" (or something like that?)
in respect to the block where it is coded.
So in the above example, do you really need to evaluate what is inside the <xsl:result-document>?
Strictly you don't, because you already know the result of the evaluation: nothing!
If fact there is another "trick" in the processors that says: when you have to evaluate this instruction,
even if you already know the result (eg. nothing), you evaluate it anyway. Because without such
a trick you would never need to evaluate any <xsl:result-document>.
With the other WG solution, you would have had to evaluate it as it would have produced a "pointer".

Conceptually, what is inside <xsl:result-document> is "another program" that produces an output
to the file you specified in the arguments. But this "program" does not affect at all the "main"
program, and so they could be run as independent programs, parallelised, differed or whatever...
The only thing the "included" program needs, is the initial context from where it has been started.

In fact, before I could use XSLT2.0, I did the equivalent of <xsl:result-document> with a batch
file running different (or same) transformations in XSLT1.0.

My workaround was quite simple, I replaced <xsl:result-document ...> </...>
by <my:result-document ..> </...>
That works anywhere, temporary or final output, no XTDE1480 error ever!
Of course it produces a node with content inside instead of nothing, so you have to take
it into account if you do things such as $temp[n] above, or a count.
At the end you have a result with your "initial" final result mixed with all the my:result-document's.
You then add a transformation that sorts out the "final" document from the "my:result-document".
It is the exact same thing you described, Michael, of course as I cannot change the XDM, the
inside "my-result-document's" are visible in the first output, they are not just pointers.

So, thank's again Michael, now I understand the trade-off you had to make with the norm
... and I am reassured; I was not delirious when I found this error "suspicious".

I still think you could have make the error "recoverable" without having to break all lazy
evaluation routines. For example a "flag" to the processor to apply the strategy that was
rejected by the WG would have been nice! Compulsory option for conformance of course.
The thing I don't know is how difficult this strategy would be to code for a processor as it
might modify some core classes related to XDM Data Model... so may be I'm being unrealistic!

Best regards

Current Thread