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

Re: [xsl] Duplicate Elimination


Subject: Re: [xsl] Duplicate Elimination
From: Ihe Onwuka <ihe.onwuka@xxxxxxxxx>
Date: Thu, 13 Mar 2014 14:11:11 +0000

On Thu, Mar 13, 2014 at 1:50 PM, Abel Braaksma (Exselt) <abel@xxxxxxxxxx> wrote:
>
> On 13-3-2014 13:11, Ihe Onwuka wrote:
>> On Thu, Mar 13, 2014 at 11:56 AM, David Carlisle <davidc@xxxxxxxxx> wrote:
>>> It's iterating through representatives of the quotient set if you factor
>>> by the relation implied by the group-by clause.
>> A union (B difference A). People who speak English will understand that.
>
> Not sure where this is going, but I personally don't immediately grab
> either explanation, they both require a double or triple read. That
> might be my lack of English, or my lack of understanding the underlying
> problem. However, I do know that I find grouping, when expressed in XSLT
> 2.0+ terms, fairly understandable on itself.
>

Then I'm glad I backtracked on the linguistic jingoism.

I was taught A union (B difference A) in Form 1 of High School in
Nigeria (can't account for educational standards in the rest of the
world - oops more jingoism). For the Americans Form 1 is whatever you
are supposed to be doing in school at age 11.

>>>> will not work for anybody restricted to XSLT 1.0
>>>
>>> It's easy to rewrite any such use of for-each-group as xsl-for-each plus
>>> a filter using a key (look up muenchian grouping for the details)
>>>
>> Easy for who?
>>
>> Where's that quote from Mike Kay that use of xsl:key should be common
>> knowledge in XSLT development - which obviously suggests that it is
>> not.
>
> Whether or not Michael Kay has at some point in time considered it
> should be common knowledge or not does not really matter towards people
> that require any kind of grouping in XSLT 1.0. Since grouping is such a
> common requirement, I think most XSLT 1.0 programmers are acquainted
> with some form of grouping, whether it is Muenchian grouping or another
> form.
>
> Whether it is "easy" is hard to say and depends highly on the
> individual, I think. For instance, many of my programmers can write a
> Bubble Sort algorithm down on paper during an interview, but I wouldn't
> be able to. Yet for me, Muenchian grouping is "easy", but then again, I
> have had my share of XSLT 1.0 grouping challenges. For just about any
> programming pattern, using it becomes "easy" once you grasp its
> principles, but if you've never used it, the abstractness of a pattern
> may make it hard to grasp at first.
>
> You wrote about explaining it to your client. I wouldn't use that term
> if I explained it to my client, I would just say something like
> "key-based grouping improved performance, which is why we chose it". But
> performance was not an issue, so I guess this argument is void ;).
>
> For a quote from Michael Kay, here is one that I found
> (http://www.oxygenxml.com/archives/xsl-list/200412/msg01020.html) when
> googling his name and Muenchian grouping, where he writes:
>
> "Muenchian grouping makes it easy to group on the result of any path
> expression, e.g. [....]"
>
> But surely, that doesn't mean it is "easy" for everyone ;).
>

I've always seen it as a hack for a missing language feature, isn't it?

Easy to me means something one doesn't have to look up. It is
something that I have read about, implemented in code a long time ago
and forgotten - partly because of infrequent use , partly because it's
a hack and partly because it hasn't got a descriptive name (Muench is
a person not a verb).


Current Thread
Keywords