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
On 7/23/17, 6:56 PM, "Graydon graydon(_at_)marost(_dot_)ca"
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
On Sun, Jul 23, 2017 at 11:08:53PM -0000, Toshihiko Makita
tmakita(_at_)antenna(_dot_)co(_dot_)jp scripsit:
> > If that's what you're trying to achieve, then it isn't going to work:
> >you're trying to create packages that aren't sufficiently independent of
> > each other.
>
> The insufficiency comes form XML document (DITA) content model itself. For
> instance:
>
> - concept/body can contain dl, ol, ul, p, table, etc...
> - p can contain inline elements ph, b, i, u, sup, sub. It also can contain
> block elements dl, ol, ul, table.
> - Inline elements ph, b, i, u can contain each other.
> - table/tgroup/tbody/row/entry can contain inline elements ph, b, i, u,
sup,
> sub. It also can contain block elements dl, ol, ul, table.
>
> The content model is recursively defined. So it will be difficult to make
> independent package unless forcing all of the element template to be
written
> in one package.
DITA's design trades a *lot* of comprehensibility for generality, and
then uses element names to provide comprehensibility for someone using
DITA to write with. If you're trying to process DITA, you generally
want to go deal with the generality using the class structure,
recognizing that for processing purposes the element names are
not especially meaningful.
From that perspective, DITA is a bunch of "structural" (@class starts
with "-") and "domain" (@class starts with "+") specializations of base
classes. So if you wanted to organize DITA processing into XSLT
modules, you'd have to start with classes, rather than elements.
For example, DITA 1.3 has about 40 elements which derive from
"topic/fig" (whether structural or domain); an XSLT module could process
all of these without coming into conflict with another XSLT module
processing DITA vocabulary from another class derivation.
-- Graydon
--~----------------------------------------------------------------
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
--~--