[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC