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

Subject: RE: [xsl] A list of useful functions that aren't in the core of xsl.
From: "Michael Kay" <mhk@xxxxxxxxx>
Date: Fri, 21 Mar 2003 18:19:11 -0000
> 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.
> 
> 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.
> 
> I have also to think how to implement in XSLT 2.0 lists of 
> lists -- probably as a sequence of nodes, whose value is a sequence.

Yes, I think it probably makes sense at that stage to use a tree
structure, even if you don't actually need the paraphernalia of node
identity, node names, base URI etc that goes with it.

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx 


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


Current Thread