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

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

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


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


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


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


> 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 
depends on people defining DocBook modules, but I think there'd be more 
incentive to do so, if users knew it could be combined with other modules.  
(you'd have to address the documentation & stylesheet issues, though)

This may not please application developers, but I think that users who don't 
care enough about semantics that they would use a wysiwyg-style editor don't 
typically need domain-specific semantics.  Just create a "core" DocBook that 
has all/most of the elements needed to represent whatever document 
structures someone may desire.  Application developers not wanting to parse 
customized DTDs and stylesheets would have the option of supporting only 
that.


Matt Gruenke


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