speculating instead of comparing implementations. However, an
RTF can be optimized for addition, while a node-set must
allow fast traversal and direct (XPath-addressed) access.
Many RTFs are not used
as node-sets, thus this should make sense.
Ok, that's from an implementors point of view. From a developers point
of view, converting to a node set is a pain. Is it not possible for the
processor to initially use RTFs and then convert to a node-set
internally when needed? Excuse my naivety here, but it seems the
obvious solution.
This is what I am talking about when I am mentioning non-local
complex optimizations. What you describe is efficient only with
efficient non-local optimizations and lazy computations in XSLT.
Not every processor will do it, most processors can't even implement
proper tail recursion. This means that elimination of node-set
means impact on performance, which is not crucial though important,
and, which is much more important, even greater impact on predictability
of performance. One will never know how much it will take to execute
a stylesheet with a processor different from one it was developed with.
Does anyone actually do anything serious with an RTF anyway (without
converting to a node-set)? Im scratching my head to think of an example
where the processor would be wasting processing time using node-sets
over RTFs.
Yes, many HTML stylesheets generate identical headers/footers/menus
for many pages of a site. Those are just RTFs reused in several places.
Nothing is wrong with that, the repeated fragments are in the target
files, not in the source.
David Tolpin
http://davidashen.net/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list