This is a rule that has been in
the spec for some time, but which wasn't enforced in Saxon until 8.4.
In previous releases if you wrote two result documents to the same URI,
the second overwrote the first (and in theory it's unpredictable which
one that will be).
The reason for the rule in the
spec is that it's not possible to define what the effect should be,
therefore it either has to be implementation-dependent or an error, and
the WG decided the latter. (Don't blame me, guv!)
I'm puzzled that you seem to be
implying this error is reported before the transformation even starts.
This is definitely a dynamic rather than a static error.
Michael Kay
Is this a no-side effects concern? It seems to work in Saxon8.2 but not
in Saxon8.4.
I'm trying to put indirection on <xsl:result-document> as follows:
<xsl:stylesheet
version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:variable name="src">
<doc>
<content filename="content1">
Content of element one
</content>
<content filename="content2">
Content of element two
</content>
<content> <!-- @filename omitted -->
Content of element with missing filename
</content>
</doc>
</xsl:variable>
<xsl:template match="/">
<xsl:for-each select="$src/doc/content">
<!-- dont try this without a filename attribute -->
<xsl:if test="@filename != '' ">
<xsl:result-document href=""
class="moz-txt-link-rfc2396E" href="mailto:../../%7B@filename%7D.xml">"../../{@filename}.xml">
<xsl:copy-of select="."/>
</xsl:result-document>
</xsl:if>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
It feels like Saxon8.4 is suspicious of my attempt to
write to the same result file more than once, but it hasn't even given
me the chance to prove my innocence of that sin by throwing a
configuration error before the transform even starts. I really do mean
to obey the no side effects law although I admit I really don't think
writing to the same output file is a side effect in the transform but
rather a side effect in the external system. If the external system
does not have side effects then all hope for transactional processing
seems lost.
Thanks again for Saxon!!
Roger Kovack
------------------------------------------------------- This SF.Net
email is sponsored by Yahoo. Introducing Yahoo! Search Developer
Network - Create apps using Yahoo! Search APIs Find out how you can
build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________ saxon-help mailing list
saxon-help-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/saxon-help
------------------------------------------------------- This SF.Net
email is sponsored by Yahoo. Introducing Yahoo! Search Developer
Network - Create apps using Yahoo! Search APIs Find out how you can
build Yahoo! directly into your own Applications - visit
