Re: XSL Optimizations

--Lars M.
>Another, and rather more ambitious idea is to turn patterns upside
>down and have a map from element type names to patterns that may match
>some descendant of that element type. Patterns can then be added to
>and removed from this list on the way down the tree and patterns
>invoked when their last requirement has been satisfied.

Isn't this called a dataflow architecture? There should be research
available from the prolog days (the Japanese fifth generation computer
project) indicating how this worked out.

My thoughts were something like this..

1) I am currently unable to get very good performance out of server-side XSL
transforms. Using the MS implementation I'm at 150ms and the LotusXSL Java
implementation is 500ms for a page fetch from the server.
2) With server-side transformations it is ok to spend a lot time when the
stylesheet is initially loaded and cached.
3)  The DTD/schema would be loaded into the cached stylesheet. The DTD would
be analyzed to figure out the minimal set of patterns that need to be
checked at each node of the DTD/schema.
4) The input document would be validated against the loaded schema and the
XSL patterns would be fired.

Would this gain anything over the current implementations? How expensive is
it to use a validation algorithm as a way of reducing patterns, I already
know the documents are valid.

Are there any XSL implementations in C or than Microsoft's? Perl and PHP are
shut out of the XSL world until there is a C implementation available.

Jon Smirl
jonsmirl@xxxxxxxxxxxx



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