RE: XSLT 2.0: Grouping proposal

Thanks for the comments, Jeni. My personal reaction:
  
> Taking my lead from the way sorting was eventually handled, I'd like
> to propose an alternative: using an xsl:group element in a similar
> way to the way xsl:sort is used, within either xsl:for-each or
> xsl:apply-templates.
> 
> I think this alternative would be easier to learn because of its
> similarity to xsl:sort, and more flexible because it can be used with
> xsl:apply-templates and because it means you can do several levels of
> grouping at the same time (though admittedly the latter is not as
> important as it is with xsl:sort).

I think this is exactly the danger with this approach. Would multiple
xsl:group elements mean that you were defining a compound grouping key for a
single level of grouping, or that you were defining multiple levels of
grouping? On the whole, I think it's clearer the way it is. I'd like to make
it easier to define a compound grouping key by allowing the grouping key to
be a sequence of values, but that depends on defining equality between
sequences. At present you have to do it using concat().
> 
> The details aren't particularly important right now - it's grouping
> with something like xsl:sort rather than like xsl:for-each that's the
> main point - but to give a better idea of where I'm coming from...
> 
> Any xsl:for-each or xsl:apply-templates would contain zero or more
> xsl:group elements followed by zero or more xsl:sort elements (the
> xsl:sort elements control the order in which the groups are processed,
> not their items).

We did decide explicitly against this. The for-each and apply-templates
instructions iterate their contained instructions exactly once for each
selected item, and I think it would be very confusing if they were to do
otherwise; it's overloading them too much. 

> 
> The xsl:group element would be empty, with one of two sets of
> attributes (though perhaps it would be better to have two distinct
> elements instead):
> 
>   - select - expression - used as the grouping key for the items
>   - collate - yes/no - used to decide whether the grouping is only
>     based on the grouping key for the preceding item (default 'yes',
>     giving the same effect as 'group-by' in xsl:for-each-group)
>   - data-type \
>   - lang       > These attributes as in xsl:sort
>   - collation /
> 
>   - test - used to identify the first or last item in each group
>   - break - before/after - used to indicate whether the node that
>     tests true (defaults to 'before', so the items that test true
>     begin the group)
> 
> (I think a 'test' (boolean expression) is more general than a 'match'
> (pattern); in particular it means that you could group sequences of
> simple-typed values in the same way.)

Most of the use cases for match use a simple element name, e.g.
group-starting-at="h2", and I guess people could learn to write
group-starting-at="self::h2" instead (or ". instance of element h2" if you
prefer!). We know that other patterns such as "appendix//h2" can always be
inverted to something like "self::h2[ancestor::appendix]". But it's not
clear to me that the generalization to simple-typed values makes this worth
doing.


Mike Kay

Received on Monday, 7 January 2002 07:28:33 UTC