RE: two questions on Oracle XSL

> can process all of them, and saxon still has a few bugs (which I am
> sure Michael is beavering away on).

I've just published a list of known errors on the SAXON discussion list, I
do suggest that all SAXON users should join this at
http://saxon.xsl.listbot.com/

I'm now treating any nonconformance with the spec as a bug even where it's a
"should" rather than a "must" item (of which there are a great many, which
is a shame for users wanting portability). As a result, the errors are
getting increasingly trivial but also increasingly numerous. Do please tell
me about anything you find, however trivial it is.

Thanks for your patience in giving SAXON 252 minutes of your computer's
precious time! Clearly a lot of the algorithms for grouping and eliminating
duplicates have n-squared performance if implemented without optimization,
so you're right that there is room for progress in this area. Possibly one
of the easier things that will make a difference is lazy evaluation of
node-set values: currently SAXON does this within a location path
expression, but in an equality test such as node-set-1 = node-set-2 (which
often arises in these algorithms) both node-sets are fully evaluated, which
will often be quite unnecessary since you can stop when you've found the
first matching pair. The tricky bit is that the best strategy is to evaluate
the smaller node-set, how do you know in advance which this is? I need to
reread all that 1980s stuff about relational join optimizations.

Meanwhile I've seen stylesheets where a dramatic improvement is possible by
replacing following::x with following-sibling::x or following-sibling::x[1].

PS: referring back to your subject line, I would try normalize() which was
the previous name for normalize-space().

Mike


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