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.
On 7/23/17, 6:56 PM, "Graydon graydon@xxxxxxxxx"
On Sun, Jul 23, 2017 at 11:08:53PM -0000, Toshihiko Makita
> > 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
> > each other.
> The insufficiency comes form XML document (DITA) content model itself.
> - concept/body can contain dl, ol, ul, p, table, etc...
> - p can contain inline elements ph, b, i, u, sup, sub. It also can
> 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,
> sub. It also can contain block elements dl, ol, ul, table.
> The content model is recursively defined. So it will be difficult to
> independent package unless forcing all of the element template to be
> 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.