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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

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

Subject: [docbook-tc] Proposed modular hierarchy: diagrams, examples

I put together a couple of diagrams showing how parts of the current
hierarchy could be grouped into smaller modules.

The first diagram is a modification of Figure 5-1 from page 93 of
DocBook: The Definitive Guide.


The intent of that diagram is to show that all the actual hierarchical
element definitions could be grouped into separate dbhier.*.mod files
(e.g. dbhier.book.mod, dbhier.refentry.mod, etc.), which would
basically leave the dbhier.mod file as a driver file.

The second diagram shows one way in which the hierarchical elements
could be grouped to form sub-modules.


Here's text listing of the same groupings:

  * sections module:        Section, Sect1-Sect5, Simplesect
  * refentry module:        Refentry and its child hierarchy
  * article  module:        Article (and Articleinfo)
  * navigational          
    components module:      ToC, LoT, Index
  * supplemental          
    components module:      Appendix, Glossary, Bibliography
  * book and set module:    Book, Set, Part, Partintro, Reference,
                            Preface, Chapter, Dedication, Colophon

I also hacked the 4.1.2 distribution to show how this could actually
be implemented. The modified distribution is at:


It doesn't change any content models in the DTD, so anything that'll
validate against 4.1.2 will also validate against this modification.
It just splits the hierarchy into separate files, like this:


The dbhier.*.mod naming convention is arbitrary -- it just seemed like
the simplest name choice.

If a DTD implementor wanted to restrict document authors to just
authoring at (for example) the Section level, this modularization
would allow him or her to do that with just a simple customization
layer like this:

  <!ENTITY % book.hier.module         "IGNORE">
  <!ENTITY % article.hier.module      "IGNORE">
  <!ENTITY % navi.hier.module         "IGNORE">
  <!ENTITY % supplement.hier.module   "IGNORE">
  <!ENTITY % refentry.hier.module     "IGNORE">

  <!ENTITY % DocBookDTD
    PUBLIC   "-//OASIS//DTD DocBook XML V4.2//EN"

I think that's a capability which'll be really useful to DTD
implementors looking for an easy way to enable non-"book-oriented",
more "modular" document authoring with DocBook.

And it seems like a change that wouldn't cost us anything -- it think
it'd 100% backward compatible.

I reckon others have probably already considered doing some kind of
further modularization of the DTD. Any comments on the approach to it
that I've outlined here?


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

Powered by eList eXpress LLC