[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re[4]: Aggregate
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|