MENU


Module Assembly

<xsl:package>, <xsl:use-package>, <xsl:override>, <xsl:expose>, <xsl:accept>

A package is a reusable, independently-compiled stylesheet module. The example below defines a package P that publicly exposes its templates T1 and T2, uses another package Q (accepting only its public T1 and T2 components), overrides Q's private variable C by adding 3 to its original value, and declares its own public template T. 

<xsl:package name="P"  version="3.0"
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:expose component="template" names="T1 T2"
                     visibility="public"/>
  <xsl:use-package name="Q">
    <xsl:accept component="template" names="T1 T2"
                      visibility="public"/>
    <xsl:override>
      <xsl:variable name="C" visibility="private"
                          select="$xsl:original + 3"/>
    </xsl:override>
  </xsl:use-package>

  <xsl:template name="T" visibility="public">
    <xsl:value-of select="$A"/>
  </xsl:template>
</xsl:package>
<xsl:accept> has very similar syntax and semantics to <xsl:expose>. Where <xsl:expose> lets a package restrict the visibility of its own components to other (using) packages, <xsl:accept> lets a package restrict the visibility of components exposed by a package that it uses — useful when a package uses two other packages whose component names conflict, or simply when only a small subset of a used package's functionality is needed.

A template rule that overrides another template rule can invoke the overridden rule with <xsl:apply-imports> or <xsl:next-match>. <xsl:apply-imports> only considers template rules in imported stylesheet modules; <xsl:next-match> considers all other template rules of lower import precedence and/or priority, as well as declarations of the same precedence and priority that appear earlier in declaration order. <xsl:apply-imports> can contain <xsl:with-param> as a child element; <xsl:next-match> can contain <xsl:with-param> and <xsl:fallback>.
<xsl:package> can have the following attributes: name (uri), package-version (string), version (decimal), input-type-annotations ("preserve" | "strip" | "unspecified"), default-mode (eqname | "#unnamed"), default-validation ("preserve" | "strip"), default-collation (uris), extension-element-prefixes (prefixes), exclude-result-prefixes (prefixes), expand-text ("yes" | "no"), use-when (expression), xpath-default-namespace (uri).
The component attribute of <xsl:expose> and <xsl:accept> can take the values "template", "function", "accumulator", "attribute-set", "variable" or "mode".
The visibility attribute can take the values "public", "private", "final", "abstract", "hidden" or "absent".
<xsl:override> can contain the following child elements: <xsl:template>, <xsl:function>, <xsl:accumulator>, <xsl:variable>, <xsl:param>, <xsl:attribute-set>.

<xsl:global-context-item>

<xsl:global-context-item> declares the required type of the item supplied as the global context item for the whole transformation.
<xsl:mode typed="lax"/>
<xsl:global-context-item use="required" as="document-node(schema-element(my:invoice))"/>

The transformation fails unless the global context item is valid against the top-level element declaration my:invoice and has been annotated as such. Setting typed="lax" on the mode further means that, in a match pattern for a template rule in this mode, an element name corresponding to a schema element declaration refers only to validated elements — for example match="employee" only matches a validated employee element. This lets the processor perform more compile-time type-checking against the schema, for instance flagging misspelled element names or a path expression that confuses an element with an attribute.

<xsl:include>, <xsl:import>, <xsl:apply-imports>

In the example below, doc.xsl defines a template that wraps the content of an <example> element in <pre>. The main stylesheet imports doc.xsl, conditionally includes dummy.xsl only when the xsl:vendor system property equals "vendor-A" (via use-when), and overrides the imported template for <example> so that its output is additionally wrapped in a red-bordered <div>, calling <xsl:apply-imports/> to invoke the original, imported template. 

<!-- doc.xsl -->
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0"
       xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:fn="http://www.w3.org/2005/xpath-functions">
   <xsl:template match="example">
     <pre><xsl:apply-templates/></pre>
   </xsl:template>
</xsl:stylesheet>

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0"
       xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:fn="http://www.w3.org/2005/xpath-functions">
   <xsl:include href="dummy.xsl"
           use-when="system-property('xsl:vendor')='vendor-A'"/>
   <xsl:import href="doc.xsl"/>
   <xsl:template match="example">
      <div style="border: solid red">
         <xsl:apply-imports/>
      </div>
   </xsl:template>
</xsl:stylesheet>
Applying this stylesheet to an <example> element gives <div style="border: solid red"><pre>...</pre></div>: the overriding template supplies the red border, while <xsl:apply-imports/> delegates the inner content to the template imported from doc.xsl.

<xsl:import> is similar to <xsl:include>, except that instructions in the imported stylesheet can be overridden by instructions in the importing stylesheet and in any stylesheet it includes; instructions brought in with <xsl:include> cannot be overridden this way.