RE: Computational complexity of XSL processing

> > The question is about computational complexity of XSL processing. 
>  
> Even though it is possible to implement XSL with such expressive 
> match patterns, it is harder to optimize them such that performance
> doesn't degrade rapidly as a function of match pattern complexity.
> It's certainly possible, but not easy.

I don't think it's especially difficult. Given the total set of templates in
a stylesheet, I think it's relatively easy to build a list of possible
templates for each element type, in order of selectivity, and because of
your other point below, I think this list will usually be very short.

One architectural point though: this optimisation could be more effective if
the XSL stylesheet was bound to a DTD. What I'd really like to do is take a
stylesheet and a DTD and generate executable code that can process any
document conforming to that DTD...

> 
> From my experience, people seldom really use extremely complex 
> match patterns anyway. Most people seem to treat match patterns
> and select patterns much like a case statement nested inside an
> if block.
> 

Agreed. I've only found one case where I really needed anything more
elaborate than "element-name", "*", "element-name/*", and
"parent-element/child-element". I usually prefer to handle anything else by
conditional processing within the template. If there was an inheritance
mechanism that allowed more than one rule to be applied, it might be
different.

Mike Kay


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