> > ...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