At first, my old implementation does something like:
<xsl:variable name="mayContinue">
<xsl:choose>
<xsl:when
test="some_big_test_over_big_xml_trees_which_was_very_slow">1<
/xsl:when>
<xsl:otherwise>0</xsl:otherwise>
</xsl:choose>
<xsl:if test="$mayContinue=1">
<xsl:if
test="other_big_test_to_check_if_something_will_be_processed">
<!-- print header -->
<!-- process data and generate output -->
<!-- print bottom -->
</xsl:if>
</xsl:if>
It can't do exactly that because you can't access a variable within its own
definition, but perhaps you just left out the </xsl:variable> end tag.
.....
<xsl:if test="$mayContinue=1">
<xsl:variable name="processOutput">
<!-- process data and generate output -->
</xsl:variable>
<xsl:if test="string-length($processOutput)!=0">
<!-- print header -->
<xsl:value-of select="$processOutput"/>
<!-- print bottom -->
</xsl:if>
</xsl:if>
But I am afraid that when $processOutput will be too big (for
example 100000
lines of text output), test for it's string-length may be slow.
As I mentioned, it depends on the processor as to whether it optimises this.
Although Saxon will optimise the test string-length($X) = 0 to the
equivalent of string($X) = '', it will still do the conversion of the result
tree fragment to a string, which is probably the expensive part of the
operation. It might be cheaper to test if $x contains any text nodes, that
is: test="xx:node-set($X)//text()" or in 2.0 simply test="$X//text()".
But as mentioned before, it all depends on what your XSLT processor chooses
to optimise, which you can only tell by measurement.
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>
--~--