Re: [xsl] Dynamic XSL Templates

Subject: Re: [xsl] Dynamic XSL Templates
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Mon, 19 Nov 2001 16:36:25 +0000
Hi Bryan,

> Thanks for the info. How "standard" are extension functions? I am
> using Xalan, so is the use if evaluate going to tie me to Xalan?

Extension functions are only standard amongst the implementations that
support them. Whether it ties you to Xalan depends on how you write
it. You could write something like:

    <xsl:when test="function-available('evaluate')">
      <xsl:value-of select="evaluate(...)" />
    <xsl:when test="function-available('xalan:evaluate')">
      <xsl:value-of select="xalan:evaluate(...)" />
    <xsl:when test="function-available('saxon:evaluate')">
      <xsl:value-of select="saxon:evaluate(...)" />
      <xsl:message terminate="yes">
        This stylesheet depends on an evaluate() function.

This would make it more portable, in that at least you could move it
to Saxon without problems, and possibly more future proof, assuming
(hoping!) that XPath 2.0 includes an evaluate() function.

However, for maximum portability, you shouldn't use extension
functions; if you can get away with it, do what Chris suggested and

  *[name() = $nodeName]

which is pure XPath 1.0 and therefore usable with any conformant XSLT
1.0 processor and very probably with any other conformant XSLT
processor. If you have paths that go down several levels, you can use
a recursive template to go down step by step (as long as they're not
too complicated).
> The business case is that we have 3 documents, which have the same
> equivilant structure but different node names. So <parent><child> is
> essentialy equal to <p><c>. We can not pre-process the data to first
> transform <p><c> into <parent><child>. So, we hoped to have an
> intermediate template call the final template with the path to the
> data.

Why can't you pre-process the data? If you can't do it outside the
stylesheet, I'd recommend that you 'pre-process' the data *within the
stylesheet* to put it into a standard format that you then process. To
do this, you have to use an XSLT 1.1 processor or use a node-set()
extension function to convert the result of the pre-processing into a
node set so that you can process it. But node-set() extension
functions are a lot more common than evaluate() extension functions,
and you'll definitely get support for the
result-tree-fragment-to-node-set conversion in XSLT 2.0, so it would
be better in the long run. I think it's likely to be faster as well.



Jeni Tennison

 XSL-List info and archive:

Current Thread