[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Grouping and Sorting on value inside group
> 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|