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

[Doug du Boulay <ddb@R3401.rlem.titech.ac.jp>]

On Sunday 08 September 2002 14:20, Matt G. wrote:
>At 09:39 2002 09 05 -0400, Norman Walsh wrote:
> >A few things occur to me.
> >
> >1. The difference between 400 elements and 800 elements isn't
> >significant, just add 'em all.
>
> Doesn't scale.  Adding them is work.  Maintaining them is more work.  Why
> would the TC want to undertake all of this?

I think 800 is actually a gross underestimate. 
If you thought to cater for the 
domain specific needs of every conceivable field of expertise, 
you would quite likely head toward the 10000 element mark. 
(Think of Goedel's proof of the incompleteness of mathematics and 
apply that to documentation markup.)
Most of which the DocBook TC wouldnt have any idea what the tags actually
signify.  Does the TC even have the moral right to adjudicate on what is 
appropriate or inappropriate element naming in such areas?

>
> >2. 400 is just too many, we need to make DocBook smaller.
>
> It needs to be smaller for people who need it to be smaller.  It should be
> better customized to the problem domains of different writers.

Shades of the Roman empire here (it grew too big and collapsed).

>
> >3. Some sort of "pizza cutter" a la TEI could be invented to allow
> >selection of "just the right" elements. (But what will that do to
> >interchange?!)
>
> That has the implication of 1, doesn't it?  In which case, I still think it
> doesn't scale enough to be feasible.

Again I agree with Matt. 
Why subtract when you could simply start with
the core and add?

>
> >4. Refactoring the parameter entity structure in a more satisfying way
> >might make it easier to customize which would offer some sort of a
> >compromise between 1 and 3.
>
> Perhaps DTDs will never quite do the job.

But if the DocBook TC could produce the tools to generate 
valid DTDs for every conceivable domain by just assembling 
relevent domain specific components into the required form.
Then there is no problem with breaking existing editing software. 
Other validation and processing suites would just have to be told
how to recombine the components or use a ready combined 
DTD

If DocBook provided the core and the tools 
and left the domain specific element naming to experts in the 
relevent domains, and sub-sub-sub domains add infinitum,  
it would ultimately prove far more flexible and versatile than any
cookie cutter approach. 

Similarly with the style sheets etc. Design them as components 
which can be plugged togeather by the domain experts to satisfy their
needs. You already have an extremely well thought out 
computer hardware/software based example to work from. Use it
as a proving ground. Show that it could work.

>
> >Any thoughts?
>
> (A tidal wave of email crashes against Norm's mailbox)
>
>
> Paraphrasing how I perceive what I've read (from Norm's original email &
> others):
>     1. "DocBook should be a standard interchange format"
>     2. "DocBook should be semantically-rich, and customized towards various
>        domains"
>     3. "DocBook should be small, and therefore easy to learn"
>
> Sounds like an identity-crisis, to me.
>
> 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. One example - from last weeks New
Scientist, converting software programs to music and listening for
bugs in the code. I recallhearing last year about some group that were trying
to render the DNA sequence into some form of music for error 
detection. Basically cross community exchanges are more and 
more prolific. think quantum computing, computer vision, 
network graph theory .........
Currently there is absolutely nothing to facilitate 
generic domain specific markup and rendering, as well as 
cross domain markup. Every group out there will be developing their
own domain specific tools and no doubt fluffing it up (speaking 
from experience in the chemical informatics domain), especially so when 
they try to go cross domain, (like chemistry to publishing)

But the DocBook TC clearly sees the problem, has the right background
to implement generic solutions and could thereby provide the technology 
for delivering a single globally unified knowledge tree. It has to happen, 
its evolution, the emergence of order from the current internet chaos.

On the other hand you could leave it to the chemists to comeup with 
something vastly inferior.

Doug
(my apologies to the chemists, who are doing an otherwise 
terrific job .-)