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

On Thursday 05 September 2002 16:30, Matt G. wrote:
> 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
> >instance.
> 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
> problem.

Back in January in response to one of your queries
Norm actually suggested that there might be 
a separation of DocBook into core and sw/hw specific sections that could 
shrink the core DocBook by possibly more than 1/3. 
If size was the main issue that would have happened/be happening now.
I suspect if someone found a need for another two dozen OO programing
concepts they would be in there in a flash.

Mathematics did seem to be a special case with only a 
speculatively modest number of new elements, of arguably, 
cross domain value.

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

I can appreciate that, admire your farsightedness and agree with you
perfectly, but it would seem to be a rather indeterminate goal of the future, 
whereas I was only thinking about short term gains and hacks.

You question where to draw the line, but does there have to be a line
or can you have a fuzzy grey area near the boundary?

If you take a look at this example from TDG:

<!DOCTYPE informalequation
           PUBLIC "-//OASIS//DTD DocBook MathML Module V1.0//EN"

the <mml:math> tag cleanly separates the actual mathematics from the 
surrounding paragraph information. Contrast that with the relegation 
of maththeorem to a perverted  mml: module like this


and you find one ridiculous mml:math boundary with duplication of
markup for document structure (and a hint that math theorem doesnt belong
in a module)
On the other hand maybe there could be some fuzzy interface layer


so DocBook might know about the interface layer, but would never 
even have to know that <mml:math> and any other namespaces below it 
were an option You'll have to excuse my ignorance here,
I was just wondering.

P.S. many of the equation examples in TDG utilise the imminently redundant  
<graphic/> for the actual rendering. It could be an idea to change that to
<mediaobject> in the future. 
Not only that but in http://www.docbook.org/tdg/en/html/equation.html
the example is incorrect. Well, if it is right then I just solved Fermat's 
equation for N=1.

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

Powered by eList eXpress LLC