I think you might achieve this by first constructing a variable with a
string value,

<xsl:variable name="item" select="concat('item', $i)"></xsl:variable>

then,

apply the templates on those elements whose name is the value of the
variable "item" like this,

<xsl:apply-templates select="element()[local-name() = $item]" />


Lisa



-----Original Message-----
From: pilgrim cnonline.net [mailto:pilgrim@xxxxxxxxxxxx]
Sent: Wednesday, April 01, 2009 12:52 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: [xsl] Can templates be invoked based on the value of a
variable?

I would like to be able to invoke templates based on the value of a
variable.

I've done some Internet searching, but haven't seen what I'm looking
for, so
I don't know whether it's possible or not.  My various attempts have
failed.

My data has the structure:

<data>
    <item1>
        ...
    </item1>
    <item2>
        ....
    </item2>
</data>


I want to process the nodes <item1/> or <item2/>, but not both,
depending on
a variable derived from some other processing.  The outline of the XSL
processing
that I'd like to do is:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="2.0">

    <xsl:template match="data">

        <xsl:variable name="i">2</xsl:variable>

        <!-- $item will have a value of either "item1" or "item2" -->
        <xsl:variable name="item">item<xsl:value-of
select="$i"/></xsl:variable>

        <!--  Want to invoke template for either item1 or item2, but
not both.  -->
        <!--  Would like to avoid using a 'choose' statement.  -->
        <!--  This does not work, but is conceptually what I'm thinking.
-->
        <xsl:apply-templates select="$item" />

    </xsl:template>

    <xsl:template match="item1">
        ...
    </xsl:template>

    <xsl:template match="item2">
        ...
    </xsl:template>

</xsl:stylesheet>


I could use a <choose/> statement to do the selection based on the
$item variable,
but I'm wondering whether there is a more "elegant" way, or whether
the <choose/>
is the way to go even though the code is longer and "bulkier".

Thanks for suggestions.

-- Mike