[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
[Recent Entries]
[Reply To This Message]
Re: Mode in XSLT 3.0
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/
--------------------------------------------------*/
Current Thread |
- Re: Mode in XSLT 3.0, (continued)
- Message not available
- Toshihiko Makita tmakita@xxxxxxxxxxxxx - 25 Jul 2017 14:30:13 -0000 <=
|
|
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
RSS 2.0 |
|
Atom 0.3 |
|
|