xsl-list
[Top] [All Lists]

Re: [xsl] Duplicate Elimination

2014-03-13 09:14:07
On Thu, Mar 13, 2014 at 1:50 PM, Abel Braaksma (Exselt) 
<abel(_at_)exselt(_dot_)net> wrote:

On 13-3-2014 13:11, Ihe Onwuka wrote:
On Thu, Mar 13, 2014 at 11:56 AM, David Carlisle 
<davidc(_at_)nag(_dot_)co(_dot_)uk> 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).

--~------------------------------------------------------------------
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>
--~--

<Prev in Thread] Current Thread [Next in Thread>