OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [Fwd: [dita-users] DTD practices for DITA]

I posted this on dita-users but did not get a response. Any opinions from the TC? My concern here is that the prescribed specialization procedure for DTDs is unnecessarily limiting. On the "specialization or attributes?" thread, Barbara Douma of Compuware had remarks that seems related:
About 8 years ago we moved to a topic-based SGML CMS in which we had very heavily specialized topics, including an Introduction, Concept, Main process, Process, Task-group, Task, and innumerable reference topic types. The end result was inflexible. This was also due to the structuring DTDs, which only allowed certain topic types in certain contexts.

-------- Original Message --------
Hi. I would like to know what current practice is out there for using
the DITA DTDs. My initial thought was that the typical DOCTYPE
declaration would use the infotype-specific shell DTD, so a concept's
DOCTYPE would look like:

    <!DOCTYPE concept PUBLIC "-//IBM//DTD DITA Concept//EN" "concept.dtd">

A colleague pointed out its limitations. This shell DTD contains no
information about other info types. For instance, a topic level element
can embed other topic level elements. But if you use only concept.dtd,
you can embed only concepts. If, by contrast, you use this:

    <!DOCTYPE concept PUBLIC "-//IBM//DTD DITA Composite//EN"

Then the concept element can embed all the standard DITA topic types:
topic, task, reference and concept, as the language reference says it
should. My earlier assumption was that ditabase.dtd was for documents
with <dita> as the root element, but it looks like it's the only way to
handle multiple topic types in DTD-land no matter what root element you
work with. We have been using ditabase.dtd for all our documents.

This seems to complicate specialization. The specialization exercises in
IBM's Deep Dive presentation prescribes a topic-specific shell DTD, such
as wiztask.dtd. But it seems to me that for interoperability with other
DITA topic types, you really need a superset of ditabase.dtd. This
ditabase-superset.dtd would need to incorporate each new infotype that
you create through specialization.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]