Re: [xsl] Duplicate Elimination

[Ihe Onwuka <ihe.onwuka@xxxxxxxxx>]

On Thu, Mar 13, 2014 at 10:14 AM, David Carlisle <davidc@xxxxxxxxx> wrote:
> On 12/03/2014 23:42, Ihe Onwuka wrote:
>>
>> As suspected it was possible to avoid grouping. See the predicate
>> tacked on to B/Date.
>>
>> Thanks all.
>>
>> <xsl:apply-templates select="A/Date | B/Date[not(A/Date/text() = text())]>
>>     <xsl:sort select="." order="ascending"/>
>> </xsl:apply-templates>
>
>
>
>
> It seems unlikely that that predicate is ever going to be true (unless you
> have a structure like
>

you are almost certainly right there.

>
> I suspect you intended
>
> <xsl:apply-templates select="A/Date | B/Date[not(current()/A/Date/text() =
> text())]>
>

I was inclined to post a description of the solution rather than code,
but I  posted abbreviated code for illustrative purposes.

The actual implementation was something like

<xsl:variable name="aDate" select="A/Date"/>
<xsl:apply-templates select="$aDate | B/Date[not($aDate/text() =  text())]/>

but showing the variable caching of A/Date doesn't add to what I was
trying to illustrate (which ironically was the simplicity of the
alternative I opted for). In effect I abused the fact that the mailing
list is neither compiler nor interpreter and posted psuedo-code.

I think this is equivalent to what you have above. It worked anyway.

>
> But unlike muenchian grouping or xsl-for-each (both of which actually have a
> simpler syntax than this)
>

The for-each syntax is more verbose.

Muenchian grouping is not something I burden my short term memory with
because I hardly ever use it and and it's  a phrase that is
meaningless beyond a very select cognoscenti. What I posted can
literally be described to a layman - add all the B/Dates that aren't
in the set of A/Dates additionally it literally translates it into a
set-theoretic

A union (B diff A)

That's why I prefer it.

>
> this will (unless you have a very aggressively
> optimising XSLT engine) be quadratic in performance as the full A list is
> going to be searched for every B.
>

good point. If and when the volumes warrant performance tuning I'll
know where to start.

> Also of course using text() rather than
>
> <xsl:apply-templates select="A/Date | B/Date[not(current()/A/Date = .)]>
>
> means the code is very fragile and will break if comments spit up the text
> nodes.
>

I have been doing too much XQuery recently, but is . robust against
changes to the content model?