Subject: Re: [xsl] using position() inside Muenchian groups?|
From: Eric Scheid <eric.scheid@xxxxxxxxxxxxxxx>
Date: Wed, 15 Oct 2008 12:07:30 +1100
On 14/10/08 11:42 PM, "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx> wrote: >> I'm only at the stage of cargo culting at the moment :-( I estimate it would >> take about 2 hours of fumbling in the dark to figure out just the Muenchian >> grouping code, which could all be for naught if it turns out that position() >> within the for-each for the keyed group is relative to the subset and not >> the original set. > > Now with this email I'm not so sure you need the Muenchian method at > all ... because your output is ordered irrespective of your input > order. Your details have I hope clarified for me what I now think > you were looking for. Yeh, like I said: fumbling in the dark. I was thinking I needed to create a virtual collection of nodes to then select from and process, when instead I just needed to select from the source collection. > I see above it is always "producer" then "director" then "writer", > yet in your input data the second production of your input has the > data ordered "director" then "producer" then "writer". Which means > with any kind of grouping you would not get the correct order for the > second production, not even if you sorted it. Thinking more about what the grouping would give me I see now I was well off into the weeds. Your solution with a series of xsl:call-template is where I wanted to eventually arrive at. > I now see how you are trying to group within respective sets of > siblings that are not grouped hierarchically. Again a clue that > traditional grouping techniques we've been discussing are not applied > in traditional approaches. Yep. That's the database export format that Filemaker produces - rows, columns, repetitions. No semantic hierarchy. Hating it. > Below in eric1.xsl is code to give you what I think you want, but > only because the ordering seems by the evidence to be set by you and > not by the data. Thank you very much for this - the first solution provided does what I want, (background: I'm exporting from a database to create input files for InDesign, with their funky markup language). You've also shown me how to abstract the processing with xsl:call-template. I can now go clean up the database scripting, removing 8 superfluous export fields and also strip out the extra table-occurrences and relationships and other cruft. Very happy camper. > There is an instruction that by definition works on axes and not on > the current node list: <xsl:number/> ... but it is designed for > exposing tree positions in formatted results, I very rarely find a > need to use it in a "programming style" within my code logic. I do > find my students quickly resort to using <xsl:number/> when > position() is better, but in your case position() is *not* better. Ah, nice one. Googling the documentation of xsl:number would never have suggested this solution to me. So, to understand correctly, <xsl:number/> reports the original position in the source elements, while position() reports the position in the *selected* sub-set of nodes/elements? e.