Re: [xsl] Mode in XSLT 3.0

["Eliot Kimber ekimber@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Ibm not sure I understand the DITA-to-module issue here: Ibm not yet up to
speed on XSLT 3 modulesb&

But the implicit requirement with DITA is that you can have processing that
will handle elements based on their base types (as defined in their @class
attributes) and then, for more-specialized elements that require different
processing, override the default processing by using separate,
higher-precedence modules. The expectation is that the base modules are
immutable and only modified using overrides and provided extension points,
rather than being directly modified.

E.g., in XSLT 1 or 2 you have either processing for more-specialized elements
that overrides the base processing for the specialization base or you have
overrides of the default processing for a given base type.

In the context of the DITA open Toolkit this is done by creating new top-level
XSLTs that import overriding modules with higher precedence. Modes reflect
distinct processing tasks, not element types (e.g., ToC processing vs normal
content processing). The XSLT modules reflect either specific processing tasks
(ToC generation, table processing, etc.) or related sets of element types
(corresponding to DITA grammar modules, see below):

  <!-- Base module (lower import precedence) -->
  <xsl:template match="*[contains(@class, b topic/p b)]">
    <!-- default processing for "p"-type elements -->
  </xsl:template>

  <!-- Module for specialization of p (highest import precedence): -->

  <xsl:template match="*[contains(@class, ' my-domain/my-p ')]">
    <!-- Overrides default topic/p processing -->
  </xsl:template>

  <!-- Module for custom processing of topic/p (higher import precedence):
-->

  <xsl:template match="*[contains(@class, ' topic/p ')]">
    <!-- Custom processing for topic/p, overrides default -->
  </xsl:template>


In DITA, sets of element types (grammars) are formally defined in
bmodulesb, which reflect sets of elements with the same architectural base
and some semantic relationship, either a single structural type (map type or
topic type) or bmix-inb elements for a specific purpose (bdomainsb).
These modules are a natural and obvious basis for the corresponding
implementation modularity. DITA allows grammars to be composed together to
create distinct document types, where two DITA documents have the same
document type if they use the same set of modules. This makes DITAbs
approach to grammar definition, management, and composition very different
from other more-traditional XML applications like DocBook or JATS.

So in a DITA processor implementation you would expect to find implementation
modules that reflect the grammar modules such that the implementation
composition can match the grammar composition.