[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 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC