Subject: Re: [xsl] Mode in XSLT 3.0|
From: "Toshihiko Makita tmakita@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 25 Jul 2017 14:30:13 -0000
<!-- Module B for 'b' (higher import precedence in imported plug-in stylesheet) --> <xsl:template match="*[contains(@class, ' hi-d/b ')]" priority="5"> <xsl:apply-imports/> </xsl:template>
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 -->
<!-- Module for specialization of p (highest import precedence): -->
<xsl:template match="*[contains(@class, ' my-domain/my-p ')]">
<!-- Overrides default topic/p processing -->
<!-- Module for custom processing of topic/p (higher import precedence): -->
<xsl:template match="*[contains(@class, ' topic/p ')]">
<!-- Custom processing for topic/p, overrides default -->
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.
>From Makita-sanbs analysis it sounds like the XSLT 3 module mechanism may not match well to the natural DITA way of thinking about implementation modularity, especially if itbs not possible (or at least not easy) for a higher-precedence module to override templates in another module while taking advantage of public/private visibility distinctions.
But maybe we just need to think more carefully about how DITA processing modules and modules should be defined? The current DITA OpenToolkit code definitely reflects itbs ancient XSLT 1 roots.
-- /*-------------------------------------------------- Toshihiko Makita Development Group. Antenna House, Inc. Ina Branch Web site: http://www.antenna.co.jp/ http://www.antennahouse.com/ --------------------------------------------------*/