This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: Modularity and PE reorganization
- From: Norman Walsh <ndw at nwalsh dot com>
- To: "Matt G." <matt_g_ at hotmail dot com>
- Cc: docbook at lists dot oasis-open dot org
- Date: Wed, 11 Sep 2002 09:13:17 -0400
- Subject: DOCBOOK: Re: Modularity and PE reorganization
- References: <F29e2U8QVjp3b6uIU1G00000378@hotmail.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