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


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.

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


Matt Gruenke


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx


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