cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Prevost <>
Subject Re: Grouping and Summaries in XSLT
Date Sat, 18 Mar 2000 08:36:30 GMT writes:

> Cool!  I was thinking that not(fqhn/@Value =
> previous-sibling::ROW/fqhn/@Value)wouldn't do the trick, for some
> strange reason, but it seems to do fine.  You should also be able to
> do not(fqhn/@Value = following-sibling::ROW/fqhn/@Value), which
> would match the last occurance, instead of the first, which would be
> slightly faster, since both XT and Xalan tend to be slower with
> previous-sibling.
> Thanks for the insight.

Actually, my first impl did it that way, and produced output in a
different order than yours.  :) Interesting to know the other is
faster.  The difficulty is that either is probably O(n^2), since every
following/preceding sibling is probably actually touched every time.
:( (And even if you return true as soon as you find a true node
instead of building the node set, time is worst case O(n^2) unless you
use some dynamic programming algorithm.  Ahh, well.)

Yeah--the "for all" quantification with = and node sets leads to
interesting behavior.  It's not immediately obvious without thinking
about where the for-alls are that

fhqn/@Value != previous-sibling::ROW/fqhn/@Value


not (fhqn/@Value = previous-sibling::ROW/fqhn/@Value)

are in fact very different, and that can make it easy to miss a
possibility like this.

The fact that this sort of task seems to be strikingly common (I've
answered several questions about how to do it on comp.text.xml)
implies that grouping functionality might be a good candidate for
inclusion in a future XSLT.  Even something as simple as an index with
a heading for each letter of the alphabet needs this sort of thing
now--although you can get around that using document() if you know the
alphabet you're using.

And an index is definitely a place where the O(n^2) bite would be


View raw message