Ray,

This is right on.  You can pre-parse the XSL stylesheet
to identify what items to "squirrel" away that are needed
later on.  However, as you said, with dynamically built
xpath expressions this becomes a hard problem.

I've posted a suggested DOM/SAX unified parser that
I think can be used to solve this problem in a 
more universal manner, your comments would be cool.

Clark

On Fri, 3 Dec 1999, Ray Cromwell wrote:
> Whether or not you consider this an interesting XSLT stylesheet,
> I can assure you, there are many cases where XSLT stylesheets 
> will be "simple" and won't have XPath's grabbing data from random
> spots all over the XML document.
> 
> All I'm suggesting is, that perhaps an XSLT processor can "optimize" 
> the stylesheet after it is loaded and detect how much state has
> to be preserved for processing. It can always fall back on
> a slower processing model, but if it could detect when a 
> stylesheet could be "optimized" and give warning about what
> constructs are likely to be slow, wouldn't that be great for
> development in the same way that breakpoints and tracing are?
> 


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