Re[4]: Aggregate

[Jeni Tennison <mail@xxxxxxxxxxxxxxxx>]

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[. &gt; 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