RE: Stylesheet optimisation

> > Interesting article. Having experimented with various ways of avoiding
> > building the full tree, I'm sure many interesting transformations can be
> > done this way, but the language to achieve them won't be XSLT. XSLT
gives
> > you direct read access to the input document and append access to the
output
> 
> I was the original author of that post. I don't understand what you
> mean by saying that the "language to achieve them won't be 
> XSLT" That's
> like saying "there are many ways of inlined polymorphic dispatch,
> but the language to achieve them won't be Java" (JIT v HotSpot) or
> "there are many ways of optimizing a join, but the language
> won't be SQL"

We're talking about two different things. You're saying, I think, that there
are XSLT stylesheets where it is possible to determine statically that they
can be evaluated without keeping the whole tree in memory. That's almost
certainly true. I'm saying that the transformation capability of such
stylesheets is very limited, and that if you wanted to do serious
transformations in which neither the source nor the result tree is all in
memory at one time, then you would design the XSLT language rather
differently. To take a trivial example, you wouldn't define <xsl:number> the
way it is defined at present.

Mike Kay


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