xsl-list
[Top] [All Lists]

Re: [xsl] Duplicate Elimination

2014-03-13 06:00:03
On Thu, Mar 13, 2014 at 10:14 AM, David Carlisle 
<davidc(_at_)nag(_dot_)co(_dot_)uk> 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?

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