[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Grouping and Sorting on value inside group

Subject: RE: Grouping and Sorting on value inside group
From: "Hunsberger, Peter" <Peter.Hunsberger@xxxxxxxxxx>
Date: Wed, 12 Jun 2002 10:35:22 -0500
hunsberger peter
> Peter
> I was just thinking about this and realised that Wendell was completely
> right, of course. 
> Doesn't <xsl:for-each select="(//dataset/*/*[generate-id() = 
> 	generate-id(key('dataids', concat(local-name(..),@dataId)))])">
> filter out most of the nodes you want because it only lets through one
node
> per value of @dataId?

Well, that's exactly the point, I only want one set (row) of output for each
dataId.  Having said that, I just realized the part you were "missing" (as
you asked in your first response).  Within the for-each there is a
subsequent apply template that looks like:

	<xsl:apply-templates select="$current/*" mode="data">
      	<xsl:with-param name="key"><xsl:value-of
select="@dataId"/></xsl:with-param>
	</xsl:apply-templates>

that takes care of the job of handling the rest of the elements that are
part of a particular group.  $current has been set to the context before I
started the grouping process.  I've been trying to simplify my examples for
the list since each "column" of the group is actually a set of complicated
conditional processing. 

There may be a way of restructuring the whole grouping and sorting and
subsequent decision process.  This discussion is now starting to actually
help me figure out what's going on versus what might really be optimal.  

There's another complication in that the whole set of templates involved in
all of this is actually recursive and has to allow for groups within groups.
I suspect this will prevent me from using some key optimizations?  The best
possibility I can see is based on the fact that within all groups each
element is unique (and all groups are unique).  As a result, one could build
a key using something like:

	<xsl:key name="dataids" match="data//*/*"
use="concat(local-name(..),@dataId)"/>

where one tried to index on all two level structures that are children of
the data element no matter how deep they occurred. (This seems like a case
where some kind of schema or complex type based matching scheme would help!)
However, it's not clear to me that the performance of such a key would be
any better than passing the structures in succession as parameters to the
template...  Groups are actually specified using an explicit type attribute
on the input XML, so perhaps I could use something like:

	<xsl:key name="dataids" match="data//(*/@type='Group')/*"
use="concat(local-name(..),@dataId)"/>

But I don't know if that makes things any better (or if it's even valid
XPath)?





		
		   


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.