Jeni's Musings

I think that to get this to work, in the imported module you would have something like

<f:name.label />
<f:email.label />

<xsl:variable name="f:name.label" select="document('')/*/f:name.label" />
<xsl:variable name="f:email.label" select="document('')/*/f:email.label" />

and then use

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

(Or something similar.) This is a technique that Dimitre uses to great effect in FXSL, but it can be a bit hard to follow unless you’re familiar with the pattern.

Personally, in this scenario, I’d still be tempted to make the imported module “standalone” (by which I mean that it doesn’t contain any static errors when validated as the principal module, even if it doesn’t produce any useful output). In Chris’ set-up, I’d define the named templates in the imported module, and in Dimitre’s I’d provide templates that matched the <f:name.label> and <f:email.label> elements. They could either provide some kind of default return value, or a terminating message that warned that they hadn’t been overridden. (In fact, I think it’s particularly important to do this in Dimitre’s example, since otherwise you’ll get no warning if you forget to define those templates.)