Re: [xsl] Re: Grouping flat HTML at multiple levels

Subject: Re: [xsl] Re: Grouping flat HTML at multiple levels
From: Mark Peters <markpeters.work@xxxxxxxxx>
Date: Fri, 5 Oct 2012 10:09:59 -0400
Hi Wendell,

You're very kind to respond to my request. Thanks for your
suggestions. Unfortunately, I only had a few days to create the
stylesheets. I ended up writing a short series of stylesheets that
handled different areas of grouping separately. My solution was
similar to the first one you describe below. With my limited
knowledge, I was able to take the transformation about 90% of the way.
I'll need to spend some time in manual cleanup mode, but that's okay.

Again, I really appreciate your help!

Best,
Mark

On Fri, Oct 5, 2012 at 9:26 AM, Wendell Piez <wapiez@xxxxxxxxxxxxxxx> wrote:
> Hi Mark,
>
> Unfortunately I don't have the time to work this out in detail at the
> moment. But this is an interesting problem with at least two
> solutions, each with its advantages.
>
> The first solution is to group inside a group. It would work like this:
>
> The outer for-each-group uses group-adjacent to collect "mixed lists":
> any set of contiguous list items of either kind, possibly mixed
> together. (They'll be mixed any time you have more than one contiguous
> list.)
>
> The inner for-each-group then sorts these out by grouping adjacent
> again. This time, use a Boolean key value, something like this:
>
> <xsl:for-each-group select="current-group()"
> group-adjacent="@class=('ListNumber','ListNumberLast')">
>  ...
>
> Then inside this inner grouping, use xsl:choose to examine to see
> which sort of group you have.
>
> Method two is to pipeline or micropipeline. Pull out and group one
> sort of list, bind the results to a variable, and apply templates to
> the variable to pull out and group the second sort of list. You can do
> this either at the level of the document or of the parent of the
> lists. There are tradeoffs in this choice (micropipelining should be
> more efficient but micropipelines don't give you access to the entire
> tree so some sorts of operations are not possible without
> workarounds).
>
> With only two types of list, I'd probably go with the first method.
> (Although it will handle more than one type if you can contrive a way
> to assign distinct key values for the different kinds of lists.)
>
> I'll try to stay on top of the thread but even if I can't, I'm sure
> others can also help if you have followup questions. (As you might be
> able to infer from the .sig, my life has recently changed. Yes, I'm in
> a position to contract directly for XSLT-related services.)
>
> Cheers,
> Wendell
>
> --
> Wendell Piez | http://www.wendellpiez.com
> XML | XSLT | electronic publishing
> Eat Your Vegetables
> _____oo_________o_o___ooooo____ooooooo_^
>



-- 
Senior technical writer
Saba Software, Inc.

Current Thread