[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