Re: DOCBOOK: Re: On the size of DocBook...

["Matt G." <matt_g_ at hotmail dot com>]

> From: Doug du Boulay <ddb@R3401.rlem.titech.ac.jp>
> To: docbook@lists.oasis-open.org
> Subject: Re: DOCBOOK: Re: On the size of DocBook...
> Date: Mon, 09 Sep 2002 11:28:35 +0900
>
> > If you make it modular, so that someone can create and install ChemBook 
> or
> > MusicBook, then it satisfies 2 and 3.  Since users are likely to 
> exchange
> > documents only within their community, it would also address 1.  This
>
> The problem is that increasingly people are combining previously
> separate fields in new ways.
I gave those as examples of independent MODULES, as opposed to the single, 
exclusive customization-layer approach currently used.  The idea is that 
there should be a set of modules providing large-scale document structures 
(book, article, resume, letter, website, etc.), small scale document 
structures (i.e. tables, figures, etc.), and then potentially hundreds of 
sets of domain-specific tags that would be managed by a group of domain 
experts.  A sufficiently advanced schema technology would need to be used 
that MULTIPLE sets of domain-specific tags could be combined with each 
other, and used with (hopefully) any of the document-structure tag sets.

The problems posed by this approach then become:
 * maintaining the schemas for the core document structures in such a
   way that they can accommodate both multiple, independent sets of
   fine-grained document structure tags modules, as well as multiple,
   independent sets of domain-specific markup.

 * maintaining documentation in a similarly modular format, so that a
   given group could easily piece together a document describing ALL
   the tags included in a given set of modules simply by combining the
   documentation for each of the tag modules used

 * maintaining stylesheet modules for each of the tag modules.  The core
   document modules would also be responsible for maintaining and unifying
   localization parameterization.


In this hypothetical situation, the role of the TC would need to change, 
slightly.  Instead of simply defining a single, unified vocabulary (now 
split up into several smaller modules), the focus would expand to include 
building a more extensible infrastructure in which modules, their 
documentation, and their stylesheets can be combined.


> One example - from last weeks New Scientist, converting software programs 
> to
> music and listening for bugs in the code.
Heh, people have been doing that for probably no less than 30 years (using 
AM radios).  About a decade ago, I would use the cross-talk between my PC's 
motherboard and its 8-bit sound card to hear my programs switch between 
stages of computation involving substantially different memory-access 
patterns.


Matt Gruenke


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com