xsl-list
[Top] [All Lists]

Re: [xsl] using position() inside Muenchian groups?

2008-10-14 21:07:27
On 14/10/08 11:42 PM, "G. Ken Holman" 
<gkholman(_at_)CraneSoftwrights(_dot_)com> 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.


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--