Re: Two pass XSLT, was [xsl] nested templates?

[Alex Black <enigma at turingstudio dot com>]

> 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.

This is an interesting point, having dismissed it previously :)

I'm already in the business of creating php from xml, why not xsl from xsl?
:)

> 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?

Can you give me some example of a specific application?

_alex


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