[xsl] Re: A list of useful functions that aren't in the core of xsl.

Subject: [xsl] Re: A list of useful functions that aren't in the core of xsl.
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Fri, 21 Mar 2003 21:20:07 +0100
"Michael Kay" <mhk@xxxxxxxxx> wrote in message
news:002401c2efd6$5ee5bf30$6401a8c0@xxxxxxxxxx
> > In XSLT 2.0 this problem will simply not exist. For XSLT 1.0
> > the optimal solution will be to have just one FXSL edition
> > for all XSLT processors that implement exsl:node-set() (Saxon
> > and Xalan do) and some separate editions for some of the rest.
> >
> > I should find some time to create an FXSL version for XSLT
> > 2.0. Not only the nasty RTF type is gone there, but one can
> > use xsl:function so it will be possible to express compactly
> > in one XPath expression code that now occupies many lines.
>
> I agree. There are some people who aren't keen on this idea of putting a
> lot of logic into one XPath expression, but I have found it very handy,
> and it means you can get much more functionality onto one "screenful" of
> stylesheet, which in my view greatly aids readability.

Thank  you. Your words of encouragement are really valuable!
> >
> > Another big expectation is that sequences will work a lot
> > faster, which (I hope) will make some costly operations with
> > node-sets a lot faster
> > -- e.g. I expect adding an element at the start of a sequence
> > to take only O(1) time -- that is the previous sequence
> > should be shared -- but probably I hope too much as such
> > behaviour is not likely to be demanded by a future
> > recommendation and will be left at the discretion of
> > individual implementors.
>
> Obviously optimizers will take time to mature on this. In Saxon most
> sequences are evaluated lazily, and assessing the cost of an operation
> like inserting an element at the start of a sequence is quite difficult,
> because it all depends at what point the system decides it's a good idea
> to build the sequence in memory. Once Saxon does decide to store a
> sequence in memory, it doesn't currently do any sharing.

Mike, common subsequence sharing really makes a big difference. For example
list sharing is one of the major assumptions in estimating the time
complexity of the algorithms in

"Purely Functional Data Structures" by Chris Okasaki. Why not have the same
data structures and efficient algorithms based on them implemented in XSLT?
Even such basic operations will be significantly speeded up as obtaining the
concatenation of two lists or a list in which just one element was modified.


=====
Cheers,

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




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


Current Thread