...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?
I'm sorry, I don't understand the assumptions behind this line of
reasoning. To my mind, the RTF in 1.0 was a ghastly mess, with it's
rules that say "you can use it anywhere that a string can be used, it
then behaves like a document node converted to a string, but you can't
use it anywhere you can use a document node". Enforcing these
restrictions was a nightmare and led to really buggy and inefficient
code which I was very happy to throw away. Where exactly do you see the
merits of RTFs?
Michael Kay
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list