This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 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
http://lists.oasis-open.org/archives/docbook/200201/msg00010.html
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"
           "http://www.oasis-open.org/docbook/xml/mathml/1.0/dbmathml.dtd";>
<informalequation>
<mml:math><mml:apply><mml:divide/></mml:apply></mml:math>
</informalequation>

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

<mml:math>
<mml:maththeorem>
<mml:title>
<mml:para>
<mml:inlineequation>
      <mml:apply><mml:divide/></mml:apply>
</mml:inlineequation>
</mml:para>
</mml:title>
</mml:maththeorem>
<mml:math>

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

<imml:interfacemath>
<imml:maththeorem>
<imml:title>
<imml:para>
<imml:inlineequation>
      <mml:math><mml:apply><mml:divide/></mml:apply></mml:math>
</imml:inlineequation>
</imml:para>
</imml:title>
</imml:maththeorem>
</imml:math>

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.

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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]