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: Re: DOCBOOK: docbook vs latex

>From: Doug du Boulay <ddb@R3401.rlem.titech.ac.jp>
>To: docbook@lists.oasis-open.org
>Subject: Re: DOCBOOK: docbook vs latex
>Date: Mon, 02 Sep 2002 18:58:50 +0900
>Sorry. I dont think I do see that point.  It seems to me that
>mathematics is more fundamental and common to all of
>historianism(?), medicine, economics and in fact all of
>science including software documentation than, say the object
>oriented elements of DocBook. So I dont think you can
>legitimately compare adding new elements for expressing
>mathematics and the foundations of the computational sciences
>with adding new elements for documenting ingrown toenails for

Yeah, but where do you draw the line?  Adding math-oriented markup could 
easily balloon into hundreds of new elements, or more.  Even if you could 
find a couple dozen elements that seem eminently reasonable to add, there 
are continual complaints about the current size of the docbook vocabulary.  
In other words, your complaint is valid, but your prescribed solution not 
only doesn't scale, but exacerbates a serious (according to some) existing 

The way to go is to partition different sets of semantics into fine-grained 
modules that can be selectively combined and layered to produce different 
document types oriented towards the needs of one problem domain or another.

It's clear that some thought was already given to this idea, and the 
approach was basically adopted to the extent allowed by DTDs.  However, 
that's where most of the scalability problems lie.  What's really needed is 
a more powerful schema mechanism, which doesn't need to rely on overriding 
parameter entities (which is really among the root causes limiting the 
number of external modules that can easily and independently co-exist, on 
top of DocBook).  Furthermore, in order to prevent collisions between 
elements with the same name, from different modules, a scoping mechanism is 
required (XML Namespaces would do nicely).

However, I think there are two primary reasons DocBook hasn't gotten away 
from DTDs.  The first is one of support by tools (it would also break 
compatibility with SGML, which a small, shrinking minority would find 
unacceptable).  Fortunately, the situation is (slowly) improving, I think.  
Secondly, the DocBook TC seems to have a more narrow-minded goal than 
creating a highly-scalable, semantics-oriented framework for replacing 
LaTeX.  Partitioning the current DocBook vocabulary, and architecting a 
fashion in which modules (and their accompanying stylesheet and 
documentation modules) for different topics and can independently co-exist 
and be seamlessly layered is a lot of work.

So, before DocBook can meaningfully scale beyond basically allowing only a 
single customization layer, there must be better tools-support for the 
enabling technologies, and the TC must have motivation to do something so 

Matt Gruenke

MSN Photos is the easiest way to share and print your photos: 

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

Powered by eList eXpress LLC