Re: using position() inside Muenchian groups?

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.