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.

  http://www.logopoeia.com/docbook/modules_new.png

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.

  http://www.logopoeia.com/docbook/hier_modules.png

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:

  http://www.logopoeia.com/docbook/docbkx412_hier_mods.zip

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:

  dbhier.article.mod
  dbhier.book.mod
  dbhier.navi.mod
  dbhier.refentry.mod
  dbhier.sect.mod
  dbhier.suppl.mod
  dbhierx.mod

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"
             "/usr/lib/xml/dtd/docbkx412/docbookx.dtd"
  >
  %DocBookDTD;

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?

  --Mike






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


Powered by eList eXpress LLC