Jeni's Musings

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

Right, Jeni,

This is is not necessary in the case of FXSL (for XSLT 2.0), because the code of the imported modules is organised as xsl:function s and is accessed through function calls. In case any template reference parameter were not supplied there would be a static compile time error, noting the wrong number and/or wrong type of the arguments passed to the function.

Cheers,

Dimitre Novatchev