W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2002

Re: XSLT 2.0: Grouping proposal

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 7 Jan 2002 17:07:42 +0000
Message-ID: <930623784.20020107170742@jenitennison.com>
To: "Kay, Michael" <Michael.Kay@softwareag.com>
CC: xsl-editors@w3.org
Hi Mike,

Thanks for your reply :)

>> 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?

My intention was a compound grouping key for a single level of
grouping - simpler than using concat(), in particular given the
different parts of a grouping value might be of different data types -
in the same way as multiple xsl:sort elements essentially give you a
compound sort key.

> 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().

Yes, it would be nice if you could group based on a sequence of
values; it would also be nice if you could create compound key values
(especially useful if you need to mirror identity constraints from XML
Schema).

>> 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.

I disagree (though not particularly strongly). To me it makes more
sense for both xsl:for-each and xsl:apply-templates to both work in a
slightly different way in the presence of a new element, rather than
introducing a new instruction that looks a lot like xsl:for-each (to
the extent that it shares the first part of its name), but works very
differently from it. But it's hard to guess what people will find more
intuitive without testing.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Monday, 7 January 2002 12:07:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:52 GMT