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
<B><Date>aaa<A><Date>aaa</Date></A></Date></B>
but that would sort with the string value of the B element and nested A
element, which would be odd.
I suspect you intended
<xsl:apply-templates select="A/Date | B/Date[not(current()/A/Date/text()
= text())]>
But unlike muenchian grouping or xsl-for-each (both of which actually
have a simpler syntax than this) 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.
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.
David
________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________
--~------------------------------------------------------------------
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>
--~--