Thanks for your fast reply Michael :)
Hmmm... I am not sure that I understand why the processor needs to call
dummy() more than once, since the [1] filter clearly states "give me
only the first node".
I would expect that the processor will call dummy() until it will
receive a true then stop because of the [1] filter.
I wonder if there is some way of re-writing these expressions in order
to get the desired result?
Thanks again,
Adrian.
On 22/06/2010 12:02, Michael Ludwig wrote:
Adrian Herscu schrieb am 22.06.2010 um 11:33 (+0300):
<xsl:template match="/document">
<document-report>
<xsl:for-each select="descendant::section[utils:dummy(true())][1]">
<section-report ref="{...@ref}"
proc-ref="{ancestor::chapter/@name}" />
</xsl:for-each>
</document-report>
</xsl:template>
In this case the console will show that dummy() was called *once*
My guess is that the processor, having established that the [1] filter
eliminates all but the first node, optimizes the other calls away.
The problem is with the variants of
descendant::section[utils:dummy(true())][1]:
1. xsl variables:
<xsl:variable name="sections" select="descendant::section" />
and then use this XPath expression instead
xalan:nodeset($sections)[utils:dummy(true())][1]
then the dummy() function will be called 4 times (while the output xml
will remain the same) !
The processor doesn't optimize this expression?
2. paths with more than one fragments:
(chapter/section[utils:dummy(true())])[1]
(chapter/section)[utils:dummy(true())][1]
((chapter/section)[utils:dummy(true())])[1]
in these cases the dummy() function is called 4 times too (while the
output xml still remains the same) !
The processor doesn't optimize these expressions either?
