OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: DOCBOOK: Re: Modularity and PE reorganization

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

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

[1] <biblioentry id="bib.maler96"><abbrev>MalerAndal96</abbrev>
	<title>Developing SGML DTDs</title>
	<subtitle>From Text to Model to Markup</subtitle>
	    <surname>El Andaloussi</surname>
	  <publishername>Prentice-Hall PTR</publishername>
	    <city>Upper Saddle River</city>
	    <state>New Jersey</state>

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC