[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK: Re: On the size of DocBook...
>A few things occur to me. > >1. The difference between 400 elements and 800 elements isn't >significant, just add 'em all. Doesn't scale. Adding them is work. Maintaining them is more work. Why would the TC want to undertake all of this? >2. 400 is just too many, we need to make DocBook smaller. It needs to be smaller for people who need it to be smaller. It should be better customized to the problem domains of different writers. >3. Some sort of "pizza cutter" a la TEI could be invented to allow >selection of "just the right" elements. (But what will that do to >interchange?!) That has the implication of 1, doesn't it? In which case, I still think it doesn't scale enough to be feasible. >4. Refactoring the parameter entity structure in a more satisfying way >might make it easier to customize which would offer some sort of a >compromise between 1 and 3. Perhaps DTDs will never quite do the job. >Any thoughts? (A tidal wave of email crashes against Norm's mailbox) Paraphrasing how I perceive what I've read (from Norm's original email & others): 1. "DocBook should be a standard interchange format" 2. "DocBook should be semantically-rich, and customized towards various domains" 3. "DocBook should be small, and therefore easy to learn" Sounds like an identity-crisis, to me. If you make it modular, so that someone can create and install ChemBook or MusicBook, then it satisfies 2 and 3. Since users are likely to exchange documents only within their community, it would also address 1. This depends on people defining DocBook modules, but I think there'd be more incentive to do so, if users knew it could be combined with other modules. (you'd have to address the documentation & stylesheet issues, though) This may not please application developers, but I think that users who don't care enough about semantics that they would use a wysiwyg-style editor don't typically need domain-specific semantics. Just create a "core" DocBook that has all/most of the elements needed to represent whatever document structures someone may desire. Application developers not wanting to parse customized DTDs and stylesheets would have the option of supporting only that. Matt Gruenke _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC