Re: DOCBOOK: RFE for further modularization of hierarchy; pleasecomment

[Michael Smith <smith at xml-doc dot org>]

Hi Bob, thanks for the response. You wrote:

> 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.

Yep, you're right. Of course it's not absolutely necessary to create
separate files -- with some rearrangment, the hierarchy could all
still be kept in one file but with marked sections and parameter
entity switches for each of the groupings.

But I think there's some value in making them separate files. For one
thing, it makes it more clear exactly what the modules/groupings are.
It's also better for usability/readability: It'll make it easier for
DTD implementors to get straight to the modules they need, instead of
scrolling through one big file to find and read them.

> 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.

Absolutely. About modularizing the information pool as opposed to the
hiearchy, Maler and El Andaloussi (Developing SGML DTDs) have this to say:

  Some DTD implementors choose to store declarations for individual
  element types (particularly those in the information pool) in
  separate modules, building up a so-called "element library" that can
  be recombined in different ways for different DTDs. However, in our
  experience the complex interdependencies between information pool
  elements are easier to understand and maintain if the entire
  information pool is stored in a single module, with marked sections
  used to "modularize" individual element types.

About modularizing the hierarchy, there are interdependencies of
course -- it's less complex, I guess, but enough that you can't remove
the refentry hierarchy or the navigational components, for example,
without also redefining other content models that depend on those.

But I think it would be possible to do it easily for the book and set
module at least, because it's at the highest level in the hierarchy,
meaning no other content models depend on those elements.

  --Mike


> > 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>