[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Grouping By Column Heading (by Position, not by ID or element name)


Subject: Re: [xsl] Grouping By Column Heading (by Position, not by ID or element name)
From: "G. T. Stresen-Reuter" <tedmasterweb@xxxxxxxxx>
Date: Tue, 29 Apr 2014 21:22:51 +0100

Hi wendell,

Thanks for the feedback. Please see my follow-up questions below.

On Apr 29, 2014, at 7:56 PM, Wendell Piez <wapiez@xxxxxxxxxxxxxxx> wrote:

> On Tue, Apr 29, 2014 at 10:50 AM, G. T. Stresen-Reuter
> <tedmasterweb@xxxxxxxxx> wrote:
>> 1) How is a TD element (found in the USE attribute of my Key) able to act
as unique identifier for a TR element (it's parent)?
>
> Actually it isn't, as you would find if you had two "Fruits" columns,
> for example.
>
> As you have it declared, the key is the (string) value of the tr/td[1]
> element; it serves as a unique identifier iff that value is unique.

Understood, but what is confusing for me is that each key is actually matching
the same rows (and indeed this seems to be the case).

Ultimately, what I'd *like* to do would be to make a key that matches ONLY the
TD elements right below it, but I'm having a devil of a time figuring out how
to do that and I suspect I still don't have any real mastery of keys to begin
with. :-(

>
>> 2) How should this be done (assuming mine is not optimal)?
>
> This method is fine if you can control your columns so that their top
> cell's values are always unique.
>
> It's not even a bad way to go if limited to 1.0 logic.
>
> In 2.0 I would probably just group on the position of the items.

Unfortunately I am stuck using 1.0. I suppose that if I couldn't control the
top row's values that I could do some sort of positioning filtering to get
things to match as needed, but that's an implementation detail. My real
question is stated above.

>
>> Please note that I realize this does not require using keys (I don't think)
but I like using keys because it makes sense semantically.
>
> Indeed it does -- even in the sense that it holds up only as long as
> your semantics do. :-)

LOL, funny. Maybe semantically wasn't the right term. What I mean is, it makes
sense to me to start by splitting things up into nuggets of like data that can
be easily processed in order - pretty common need, I suspect.

Thanks again for the feedback.

Ted


Current Thread