Except that RTF can be generated much more efficiently than
node-set; and some implementations fell into a trap somewhere
around this issue while implementing extension node-set call
-- making it too inefficient. Not having to explicitely
convert RTF to a node-set can lead to either inefficient code
or to complex non-local optimizations in the processor.
...are you saying keep RTF's (and the corresponding explicit node-set
conversion) in 2.0 for performance reasons?
node-set should be kept in XSLT for reasons which are much more serious than
performance. I can see reasons why one can want to drop it; however, the
experience with XSLT 1.0 shows that node-set is a dangerous area. Having
it hidden behind the scenes just makes implementation bugs harder to discover
and computational complexity issue (for which I will eventually be linched
on this list) much more complicated.
Would you live with the fact that an algorithm which was linear in XSLT 1.0
would be quadratic in XSLT 2.0?
Do you see any advantage in turning simple and obvious operation at the level
of XSLT ( (exsl|xt):node-set ) into something optimization-based?
The fact that in SAXON it is just a single bit does not mean it is the way
to go by itself.
David Tolpin
http://davidashen.net/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list