> If you want to avoid using "//dataset" you could have a key like this:
> <xsl:key name="dset" match="dataset" use="'all'"/> 
> and access it using 
> select="key('dataset','all')"
> 
>> >>I finally found the answer.  Your use of [@dataid = 
>> current()/@dataid]
>> >>provided the missing clue:
>> >>
>> >>       <xsl:for-each select="(//dataset/*/*[generate-id() =
>> >>generate-id(key('dataids', concat(local-name(..),@dataId)))])">
>> >>          <xsl:sort select="parent::node()/*[local-name() = 
>> $sortcol and
>> >>@dataId = current()/@dataId]/value"/>
>
>
> I agree with Wendell that the whole generate-id() malarkey is redundant,
but
> it doesn't do the same thing as key('dataids',
> concat(local-name(..),@dataId))[1] because you will get every node that
> satisfies the predicate and not just the first one. 
> And every node in //dataset/*/* that has a @dataid will be in the 'dataid'
> key and satisify the predicate.

As I said in my reply to Wendell, I think this is why the generate-id works:
it groups the sets of elements by the matching dataid?

>
> So won't this work just as well:
> <xsl:for-each select="key('dataset','all')/*/*">
> 	

By itself, that returns everything ungrouped.  If I try to add grouping
logic to it I get nothing, I'm not sure why, but I'll spend some more time
trying to figure it out...

> The sort looks really cunning and probably is doing all the hard work here
> ;)

Hah, I wish, the group was returning the proper number of rows before I
every added the sort.  It just wasn't sorting them...

I'm afraid to admit this, but the more I work on this, the more confused I
get...

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