[no subject]

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



On 7/23/17, 6:56 PM, "Graydon graydon@xxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

    On Sun, Jul 23, 2017 at 11:08:53PM -0000, Toshihiko Makita
tmakita@xxxxxxxxxxxxx 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

Current Thread