Re: [xsl] following-sibling and xsl:sort

Subject: Re: [xsl] following-sibling and xsl:sort
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Sat, 30 Apr 2005 10:13:00 +1000
On 4/30/05, Karl Stubsjoen <kstubs@xxxxxxxxx> wrote:
> > Therefore, any problem, which has solution using the xxx:node-set()
> > extension function should have a solution without using it.
> I tend to disagree with that statement.  I am in the middle of a
> project now which is using xxx:node-set() quite regularly processing
> xml fragments that have been transformed, grouped, sorted and in some
> case summarized in order to drive other data validation and lookups.
> I am having to ask questions like:  "Does this item exist with this
> item? If so do they overlap, are they in correct combination with
> these other items..." and so on..  However, my XSLT is probably just
> ok, so maybe there is a better way.  I can give some examples of the
> kind of data we are validating if you are interested.


Your original question was:

  "Is the obvious (and only) solution to use xxx:node-set against
transformed / sorted XML?"

You've got the answer to this: "No"

The fact that a "pure" XSLT 1.0 solution exists doesn't mean it is
more elegant and nowhere did I recommend using such pure solution over
the corresponding xxx:node-set() one.

We must have *proofs*, not "believes" whether XSLT 1.0 is
Turing-complete or whether a Turing-complete language can express any
XSLT transformation using the xxx:node-set() extension.

Just saying that "XSLT 1.0 cannot solve taskX" is not a proof, it is a

In fact, there were such believes in the past that were proven wrong  :o)

Dimitre Novatchev.

Current Thread