DOCBOOK: Re: Modularity and PE reorganization

[Norman Walsh <ndw@nwalsh.com>]

/ "Matt G." <matt_g_@hotmail.com> was heard to say:
|>I spent some time this weekend with several hundred little slips of
|>paper[1] making a stab at a more logical set of parameter entities (or
|>at least, of classes) for DocBook.
|
| Wouldn't using physical tokens, for each element, imply that they can
| only belong to one class or module?  Certainly, where multiple

One of the constraints of the Maler+Andaloussi[1] class/mixture
methodology is that an element can appear in at most one class.

| interpretations of a term exist (e.g. "module", "class", "package",
| etc.), some duplication is acceptable and should even be encouraged.
| Using separate namespaces (if possible) for each module would help
| disambiguate collisions (for purposes of authoring, documenting, and
| processing, actually).

If they are in different namespaces, they are not the same. Assuming
that a: and b: are mapped to different namespace names, a:foo and
b:foo are as different as foo and bar.

| Hopefully, allowing duplication of elements would eliminate nearly all
| of the tough classification decisions.  Furthermore, being able to put
| them in different namespaces would allow their content models to
| differ.

The classification decisions turned out to be not too hard. Figuring
out what the right content models are (the mixtures) is proving a
little more interesting. But I haven't been thinking about it as long.

Moving to multiple namespaces isn't in the cards at the moment.

| Anyhow, one thing I noticed about your categorization is that you put
| a number of document structures in a "publishing" class (e.g. figure,
| blockquote), yet you put things I consider to be publishing (i.e.
| referring to a context outside of the document) in a "core" class
| (e.g. edition, pubdate, publisher, issuenum).  I think the fundamental

The former are elements that appear in a document as content. The
latter are "metadata" elements. They can't appear in the same sorts of
places in a document, so it doesn't make sense to put them in the same
class.

| blocks found in all types of documents (e.g. para, figure, etc.)
| should form the core,

One of the goals I'm exploring is a really tiny core.

| while larger-scale blocks (e.g. chapter, part,
| article) would go in a 'document' class (as opposed to a website

They're in a 'book' class.

| class, letter class, resume class, etc.).  Then, domain-specific terms

Letters, resumes, and websites aren't exactly in the computer hardware
and software domain.

                                        Be seeing you,
                                          norm

[1] <biblioentry id="bib.maler96"><abbrev>MalerAndal96</abbrev>
	<title>Developing SGML DTDs</title>
	<subtitle>From Text to Model to Markup</subtitle>
	<authorgroup>
	  <author>
	    <firstname>Eve</firstname>
	    <surname>Maler</surname>
	  </author>
	  <author>
	    <firstname>Jeanne</firstname>
	    <surname>El Andaloussi</surname>
	  </author>
	</authorgroup>
	<isbn>0-13-309881-8</isbn>
	<publisher>
	  <publishername>Prentice-Hall PTR</publishername>
	  <address>
	    <city>Upper Saddle River</city>
	    <state>New Jersey</state>
	  </address>
	</publisher>
	<pubdate>1996</pubdate>
</biblioentry>

-- 
Norman Walsh <ndw@nwalsh.com>      | 'tis expressly against the law of
http://www.oasis-open.org/docbook/ | arms: 'tis as arrant a piece of
Chair, DocBook Technical Committee | knavery, mark you now, as can be
                                   | offer't; in your conscience, now,
                                   | is it not?--Fluellen, Henry V