RE: XSL Compilation

Mike Kay wrote
> No, I abandoned work on the Saxon XSLT compiler, when I found that the code
> was running slower than the interpreter, and that the unimplemented features
> (including namespaces) were going to be very difficult to do.
> 
> The only XSLT compiler project I'm aware of is the one at Sun.
> 
> Personally I'm now sceptical whether it's the right way forward. How many
> successful SQL compilers are there?

It depends. All DB manufacturers i know of have a precompiler which produces
preparsed internal representation of SQL statements for faster network
transfer (using handles) and avoiding reparsing repeated statements. This
is probably equivalent to Xalans's compiled stylesheets. Some DBs do also
major optimisations in this process, sometimes resulting in quite significant
speedups (i've seen a factor 5 personally).

I'm not sure what time consuming optimisations could be applied to XSL, but
i'm sure there are some. Using term rewriting for XPath predicates might be
an application, possibly resulting in common subexpression elimination in
successive XPath statements. The "fast numbering across gaps" problem may also
be solved this way. Another possibility might be the evaluation of the DTD of
the XML to be transformed, for example if the DTD says <!ELEMENT foo (a,b,c)>
and i have an XPath "foo/x" in my XSL, it could optimise it away and possibly
emit a warning message too.

J.Pietschmann


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