Jeni's Musings

The cure for this is not to call templates in the imported module, but to use tamplate references.

So, instead of:

<dl>
  <dt><xsl:call-template name='name.label'/></dt>
  <dd><input type='text' name='name'/></dd>
  <dt><xsl:call-template name='email.label'/></dt>
  <dd><input type='text' name='email'/></dd>
</dl>

one would write:

<dl>
  <dt><xsl:apply-templates select='f:name.label'/></dt>
  <dd><input type='text' name='name'/></dd>
  <dt><xsl:apply-templates select='f:email.label'/></dt>
  <dd><input type='text' name='email'/></dd>
</dl>

There will be no redundand code in the imported module — just the namespace to which “f” is bound needs to be the same in both the imported and the importing modules.

In the importing module, instead of

<xsl:import href='layout.xsl'/>
<xsl:template name='name.label'>Your name:</xsl:template>
<xsl:template name='email.label'>Your email address:</xsl:template>

one would have this:

<xsl:import href='layout.xsl'/>
<xsl:template match='f:name.label'>Your name:</xsl:template>
<xsl:template match='f:email.label'>Your email address:</xsl:template>

To summarise, this is a demonstration of a good practice to design modularised XSLT applications, which totally avoids the problem of preventing the imported module from being able to exist stand-alone.

Cheers,

Dimitre Novatchev