Thank you for sorting out the DITA stylesheet requirement features.
>>From Makita-san’s 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 it’s 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.
Yes, as long as I see, xsl:package will not help the DITA stylesheet
implementation. It may be useful to be used in more higher independent
stylesheet sets.
> In the context of the DITA open Toolkit this is done by creating new
top-level XSLTs that import overriding modules with higher precedence.
The most important concern is this point. If one develops their own
plug-in that is not intended to be used from other plug-in, there will
be no problem. In contrast if one develops the base plug-in that is
intended to be used from other plug-in, the xsl:import instruction
should be used in the other plug-in.
I that case if the other plug-in overrides the base template (such as
'ph' template), this template has higher import precedence than all of
the imported templates.
<!-- Base module A (lower import precedence in imported plug-in stylesheet)
-->
<xsl:template match="*[contains(@class, ‘ topic/ph ‘)]">
<!-- default processing for "ph" elements -->
</xsl:template>
<!-- Base module A for specialization of ph (higher priority in imported plug-in stylesheet) -->
<xsl:template match="*[contains(@class, ' hi-d/b ')]" priority="5">
<!-- default processing for 'b'. Higher priority is needed because 'b' is
specialized from 'ph' -->
</xsl:template>
<!-- Module B for custom processing of topic/ph (higher import precedence because this is coded in template that have xsl:import/@href="A") -->
<xsl:template match="*[contains(@class, ' topic/pn ')]">
<!-- Custom processing for topic/ph, overrides default -->
</xsl:template>
The last template has most high precedence than the 'b' template. As the
result, template for 'b' become invalid. To solve this issue, we must
code all highlight-domain templates (or all of the template for the
element that is the specialized from 'ph') in import side plug-in.
<!-- 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>
I think that this problem has not been solved in DITA-OT plug-in and
XSLT 3.0 does not offer useful solution.
On 2017/07/24 23:14, Eliot Kimber wrote:
I’m not sure I understand the DITA-to-module issue here: I’m not yet up to speed on
XSLT 3 modules…
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, ‘ topic/p ‘)]">
<!-- 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 “modules”, 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
“mix-in” elements for a specific purpose (“domains”). 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 DITA’s 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-san’s 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
it’s 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
it’s ancient XSLT 1 roots.
Cheers,
E.
--
Eliot Kimber
http://contrext.com
--
/*--------------------------------------------------
Toshihiko Makita
Development Group. Antenna House, Inc. Ina Branch
Web site:
http://www.antenna.co.jp/
http://www.antennahouse.com/
--------------------------------------------------*/
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--