RE: "sorted" axis (was: Remove duplicates from a node-set accordi ng to content)

Subject: RE: "sorted" axis (was: Remove duplicates from a node-set accordi ng to content)
From: Kay Michael <Michael.Kay@xxxxxxx>
Date: Fri, 30 Jul 1999 10:16:23 +0100
> From: James Clark [mailto:jjc@xxxxxxxxxx]
> The saxon:group element is a pretty interesting extension.  My initial
> thought is why not make it an empty element that applies to its parent
> xsl:for-each or xsl:apply-templates element, like xsl:sort?  That way
> you can have multiple grouping levels: there would be one level of
> xsl:item nesting per xsl:group element.
It started life as a group-by attribute on xsl:for-each when sorting was
controlled by a similar order-by attribute. I've always been able to get by
with one level of grouping but general nesting would be far better.

I'm not sure an empty element feels right: there's a need to delineate the
processing that happens at each level of grouping, something like:

process node set X sorted by Y then Z
-- for each group with common Y do
-- <h2>Y</h2>
---- for each group with common Z do
---- <h3>Z</h3><ul>
------- for each item do
------- <li>stuff</li>
------- end for
---- </ul>
---- end for
-- end for
end process

The other thing I haven't done (which is really why I made the remark about
report writers) is to link it in with totalling; with updatable variables
it's easy enough to accumulate subtotals at each grouping level, but without
them, it's a little tricky to show a subtotal over the items in a group.
This suggests a possible need to incorporate the idea of a group into the
expression language. The road this takes you down, of course, is towards an
extended SQL.

Mike Kay

 XSL-List info and archive:

Current Thread