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