Kay Michael wrote:
 
> > This is really a question to those developing the XSL spec: is this a
> > reasonable requirement? or am I on the wrong side of the 80/20 divide?
> > is my vague hope for "sorted" axes doomed to disappointment?
> 
> It comes up so often that it MUST be a reasonable requirement. If you want
> to do it in less than 35mins, try SAXON's group-by construct.
> 
> (It's proprietary, though with extension elements becoming respectable it
> will soon become more of a "standard extension" than a "proprietary
> extension" - not that this makes any practical difference!)
> 
> The SAXON construct doesn't solve the problem by giving you sorted axes, it
> does it by allowing you to write code that in effect allows you to add a
> layer of hierarchy to a nodeset, so you can say
> 
> for each group of consecutive nodes with the same value of EXPR do
> -- start of group processing
> ---- for each node withing the group do
> ------ process the node
> ---- end
> -- end of group processing
> end

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's puzzled me for a while that the design of XSL seems to have learnt
> very little from 25 years of experience in designing report writers!)

So what should it have learnt and what should it learn in the future?

James


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list