Two pass XSLT, was [xsl] nested templates?

Subject: Two pass XSLT, was [xsl] nested templates?
From: cagle@xxxxxxxxx (Kurt Cagle)
Date: Thu, 17 May 2001 07:51:08 -0700
As an academic exercise, I've written two pass XSLT routines that generate
XSLT dynamically from a "pseudo" XSL source, and
have found an interesting phenomenon. Even taking into account the fact that
a two pass system is likely to be less efficient than a one pass system, it
added a fair amount of value. You could make XSLT more procedural this way
(for instance, by creating an <xsl:for-index> loop), you could make certain
constructs such as arrays more like their C++ and Java breathren, you could
(with a fair amount of work) implement functional XPath notation for called
templates, and could create create conditional imports, all necessary
conditions for building a larger scale framework. However, the source schema
that you had to use seemed a lot more complicated than just writing the
transformation in the first place.

Having said that, I don't think two pass XSLT is all that inefficient,
comparatively speaking. The first pass is essentially analogous to a make
file -- you are creating a stylesheet from a non-XSLT source, just as you
would write a .java file from a .class file. The resultant file could be
cached quite efficiently. The danger here is in design; you are creating a
potentially generic stylesheet from another XML file, and as a consequence,
the design should be intelligent enough to ensure that data is still
parameterized. Hmmm... some food for thought.

Does anyone else have any thoughts on this?

-- Kurt

> You can't dynamically include stylesheets. If you want to make sure
> that a stylesheet only contains the templates that it needs to perform
> a particular transformation, then you need a two-pass solution: the
> first to create a stylesheet that holds only the relevant templates
> (perhaps by including them with xsl:include), and the second to use
> this stylesheet to transform the source.
> (My instinct is that this two-pass approach is likely to be less
> efficient than a one-pass approach overall, unless you're going to
> reuse the result of the first pass multiple times.  I get the
> impression that you're worried that having the processor search
> through lots and lots of templates to find the one matching a
> particular node is a problem, that you're worried that the more
> templates you have, the more inefficient the code is going to be
> because the processor will be spending lots of time finding them?  I
> honestly don't think that's a performance problem you should be
> worried about - in all his lists on increasing the efficiency of
> stylesheets, Mike Kay has never said 'use fewer templates'.)

 XSL-List info and archive:

Current Thread