Re: [xsl] Mode in XSLT 3.0

["Toshihiko Makita tmakita@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Thank you for sorting out the DITA stylesheet requirement features.

>>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.

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, b topic/ph b)]">
    <!-- 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:
> 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.
>
> >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.
>
> 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/
 --------------------------------------------------*/