[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: RFE for further modularization of hierarchy; pleasecomment
Hi Michael, I read your proposal. There were two things that came to mind for me. 1. The DTD is already pretty highly modularized using marked sections. The marked sections allow a custom driver file to INCLUDE or IGNORE element declarations. Some of the individual element marked sections are inside larger marked sections that wrap a related group of elements. I'm wondering if this nesting of marked sections could be extended to include the DTD modules that you envision? You could achieve the same effect of selecting modules in the driver file without proliferating files. 2. After saying that the DTD is highly modularized, I have to say (from experience) that it is not completely modularized. That is, selecting certain modules to leave out can leave you with an invalid DTD. There are a lot of interconnections among the elements in the way they are used in parameter entities and content models. The reason I wrote the LiveDTD utility was to help me track those interconnections, and to unwind them when trying to remove an element. Certainly choosing among the highest level containers as you propose is less of a problem than leaving out individual inline elements that appear in many content models. But some attention has to be given to at least documenting the limits to which modules can be deselected and still have a working DTD. bobs Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: bobs@caldera.com > From: Michael Smith <smith@xml-doc.org> > > I just filed an RFE proposing further modularization of the DocBook > hieararchical elements (the stuff in the dbhier.mod file). > > http://sourceforge.net/tracker/index.php?func=detail&aid=477073&group_id=21935&atid=384107 > > I hope anyone interested can take some time to comment on it here. > > Briefly, the idea is to take content models from the dbhier.mod file > and put them into separate files/modules, like in this diagram: > > https://sourceforge.net/tracker/download.php?group_id=21935&atid=384107&file_id=12733&aid=477073 > > and here, as text: > > * sections module: Section, Sect1-Sect5, Simplesect > * reference page 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 > > Along with making the separate modules, we'd also need to add > parameter entity switches for turning on or turning off each of them. > > The rationale is that it'll make it easier for DTD implementors/ > customizers to mix and match or ignore whatever building blocks from > the standard hierarchy they choose -- so they can use only the > hierarchical bits they need and ignore the rest. It's just another > useful hook to add to all the existing hooks that DocBook has for > facilitating customizations. > > Regarding any effects on document authoring and validation: I think it > would be a transparent change. It should be 100 percent backward- > compatible -- anything that validates against the 4.1.2 DTD should > validate against this modification. > > If you want to try it out, you can grab a modified version of the > 4.1.2 XML distribution, with the proposed modules added. > > http://sourceforge.net/tracker/download.php?group_id=21935&atid=384107&file_id=12731&aid=477073 > > > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC