This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re[4]: Aggregate
- To: Kay Michael <Michael dot Kay at icl dot com>
- Subject: Re[4]: Aggregate
- From: Jeni Tennison <mail at jenitennison dot com>
- Date: Tue, 14 Nov 2000 10:27:57 +0000
- CC: "'xsl-list at mulberrytech dot com'" <xsl-list at mulberrytech dot com>, "Reddy, Nagesh" <Nagesh_Reddy at bmc dot com>, "'adduri_nagesh at yahoo dot com'" <adduri_nagesh at yahoo dot com>
- Organization: Jeni Tennison Consulting Ltd
- References: <FA209FE12D83D411BC970010A8001331508344@wwmess3.bra01.icl.co.uk>
- Reply-To: xsl-list at mulberrytech dot com
Mike,
>> So, to find the maximum of the 'in' elements, use:
>>
>> in[not(parent::TIME/in > .)]
>
> But I'd express caution, certainly for large node-sets. This is likely to be
> an O(n-squared) solution (it certainly is in Saxon). Doing an XSLT sort and
> extracting the first or last element is likely to be O(n*log(n)). Doing a
> recursive walk of the node-set as described in XSLT Prog Ref page 171 is
> likely to be O(n).
Good point. Would it make any difference if the XPath was:
in[not(parent::TIME/in > .)][1]
Would the extra positional predicate make the processor (or Saxon at
least) stop once it found the first instance, and therefore be more
efficient? Or what about a mix:
<xsl:template match="in" mode="find-max">
<xsl:variable name="greater"
select="following-sibling::in[. > current()][1]" />
<xsl:choose>
<xsl:when test="$greater">
<xsl:apply-templates select="$greater" />
</xsl:when>
<xsl:otherwise><xsl:value-of select="." /></xsl:otherwise>
</xsl:choose>
</xsl:template>
I tend to assume that XPaths are always going to be more efficient
than using equivalent XSLT instructions because processors have a
greater opportunity for optimising XPaths, but I guess that's a false
assumption, especially where there are processor optimisations on
recursion.
Thanks,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list