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

Doug du Boulay wrote:

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

Please, please, don't start flamewar.

If you use mathematics just like support tool -- for example you are
writing some formulas estimating memory and time efficiency of some
algorithm, current support of DocBook (equation and inlineequation
elements with MathML module) is IMHO sufficient.

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

If you want to use DocBook to write mathematical textbooks and articles
you are certainly lacking elements like theorem, prove, axiom,
definition... But same problem will be facing any other group of users
except computer one. Biologist will need genus and tribe and... 

DocBook was primarly created for documenting hardware and software
systems and thus it has some general usable markup and markup
specialized for hardware and software systems. If you want use it in
different area you will be probably facing problems with missing
elements for marking all the semantic needed by some discipline. But
this is not DocBook's fault, this is falt of user because he is using
wrong DTD for his purposes. If DocBook TC will add new elements for each
non-computer group of users which requests it, DocBook will shortly
became very complex monster. Even current DocBook is quite complex for
many newcomers.

I understand that you like benefits of structured content, XML,
single-sourcing and excellent support for DocBook in free and commercial
tools. I see one way of solving this whole issue which was actually
suggested by someone else few months ago on this list. It's idea of
modularization of DocBook. Current DocBook can be seen as two logicals
modules -- general and computer specific. First module contains general
use elements for structuring documents like chapters, sections, paras,
lists, tables, images, bibliographics and linking. This markup is of
general use for anyone. There is second group of elements specially
devoted for computer documentation usage. 

Anyone is free to create new DTD based on DocBook which will add other
domain specific elements than computer documentation. But I don't think
that OASIS DocBook TC is willing to do it and even should do it. But
other bodies and groups can create their own elements for theirs areas
of interest. Simillar approach is used in TEI, but markup modules are
centralized here. I don't think that this solution scales well. I like
more decentralized systems. So DocBook TC in theory can split current
DTD into two modules -- basic and computer documentation. Anyone else
can derive their own DTDs based on basic module, reusing common markup
and stylesheet support. How standard derived DTDs became depends on
informal power of group proposing it. If I will create some
mathematically oriented MathDocBook, probably few users will use it. But
if same will do ACM or Springler-Verlag this might become de-facto

> Granted, but since all we really have available at the moment are short
> term hacks I was just hoping that markup like <latex></latex> in
> db2latex could be modified for compatibility with <alt role="tex">  so that
> both toolchain hacks were accessible without redundancy and
> without violating the DocBook DTD (but maybe by enhancing it,
> if that is what it takes).

Yes. But this is task for db2latex developers.
> Clearly Ramon has identified weaknesses in the existing
> content model, and gone ahead and implemented a solution.
> If it isnt the most ideal markup notation then shouldnt  the Docbook
> developers at least try to find out what would be ideal
> and work toward some compromise? Scientific program documentation is
> still program documentation.

Maybe I'm missing something, but why you need elements like
<maththeorem> when documenting scientific program? I understand that you
must insert equations in your document, but for this case there is
existing markup in DocBook. But if you are writing math paper in DocBook
you may be in wrong shop with stock DocBook.


P.S.: I do a lot of DocBook training. Current 400 elements is a real
overhead for people who are switching from MS Word to structured content
creation. I like current DocBook TC approach which very carufully
reviews each request for adding new element.

  Jirka Kosek  	                     
  e-mail: jirka@kosek.cz

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

Powered by eList eXpress LLC