Re: Sorting on call-template value... solutions provid

"Mike Brown" <mike@xxxxxxxx> wrote in message
news:200304150608.h3F68HaJ028028@xxxxxxxxxxxxxxxxxxx
> Randy Oxentenko wrote:
> > Another gentelman named Mike Brown supplied a pointer to another
technique
> > that involves the use of extension functions, which are part of exslt.
This
> > technique would use features of XSLT that go beyond the defined
standard.
>
> IIRC, Dimitre's solution relies on an extension function, too:
exsl:node-set()
> or the vendor-specific equivalent. There are no pure XSLT 1.0 solutions.

Yes but this is a single extension function, which is a "de-facto" standard,
implemented on almost every existing XSLT processor and used massively by
the majority of people. We know that without xxx:node-set 80% or so of the
xslt solutions we're using today would be impossible or very difficult to
implement.

When some knowledgable people on this list have said that FXSL is written in
pure XSLT they knew about the usage of xxx:node-set() in FXSL.

>
> I'd be curious to know how the two solutions compare, time-wise, in
> whatever XSLT processor you are using.

This will depend on the complexity of the function, which calculates the
value of the sort key. If this function is farely simple, then using
xsl:sort  must be very fast. If this function has significant time
complexity, then both solutions will tend to have similar time complexities.


It is incorrect to compare these two approaches only for their effeciency.
An exslt:function has to be called with a fixed name. FXSL implements
functions as first-class objects, which can be passed as parameters to
higher-order functions. This is something that Exslt and XSLT 2.0 do not
provide. With higher-order functions (HOF) it is possible to develop highly
generic and reusable solutions, that are impossible without HOF.



=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL





 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list