> 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.
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:sequence select="3"/>
</xsl:variable>
<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
Alain BENEDETTI