Jeni's Musings

The other reason I would normally use named templates that depend on the context node is to factor out code that is common to a number of element types where you wouldn’t want (or be able) to simply extend the match statement. This most often occurs where you have templates that handle some base type and you want to make it easy to apply that processing to specializations of that base (either in the strict XSD sense or in the looser DITA sense of specialization).

I also try to document what the expectations on the context node are (otherwise, like you say, it can be very difficult to debug or understand later).

For example, I might do something like this:

<xsl:template match="docbook:section" name="sectionHandler">
  <!-- generic processing for section -->
</xsl:template>

and in a stylesheet for my customization I might have:

<xsl:template match="mystuff:supersection">
  <xsl:call-template name="sectionHandler"/>
</xsl:template>

Is there a more effective way to do this (short of having either type-aware templates or using DITA-style class= attributes and corresponding match values).

Cheers,

Eliot