[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: On the size of DocBook...
At 09:39 2002 09 05 -0400, Norman Walsh wrote: >The recent thread about DocBook and LaTeX raised the issue of the size >of DocBook (measured as the number of elements). (It's not the first >thread to raise the issue, just the most recent.) > >Certainly one of the complaints that new users make about DocBook is that >it's "too big". Yep, it's big. And I'm a minimalist at heart, and I share the concern about adding elements to DocBook. But just what are the user requirements in this issue? In what way does having 400 (or 800) elements in the DTD affect the end user whose document contains 10 different elements? >A few things occur to me. > >1. The difference between 400 elements and 800 elements isn't >significant, just add 'em all. > >2. 400 is just too many, we need to make DocBook smaller. > >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?!) > >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. > >Any thoughts? As far as I see it, 4 shares interchange/interoperability issues with 3. Either your application handles an element or it doesn't. I don't see how point 4 reduces any of the effort associated with creating DocBook aware tools or maintaining the DocBook application. Again, just what are we trying to accomplish? Only point 2 will make a dent on the effort to produce tools and maintain the application. And I don't see that any of the points make a dent on the end user experience. If users are saying "when I go to enter a tag, my tool shows me hundreds of possibilities and that overwhelms me," then my answer is to fix this problem at the tool level. For example, the tool should provide a way for the user (or a site administrator) to configure things so that only the tags a user expects to use are shown in the tag choosing panel. The only other effect of size is performance. And I suggest that any attempt to save milliseconds in performance is going to be overshadowed by the hours spent in interoperability problems inherent in approaches 3 and 4 above. So I don't have a particularly satisfying response. I think we should try to avoid adding elements when there is no strong reason, but if we feel a new element is important to a non-trivial population and it is within the scope of the DocBook application's purpose, we can add it. If you're trying to come up with some automatic, unbiased way to decide if we add a new element or not, I don't have a better answer than our current process--the TC gets to decide. If you don't like that, join the TC. paul
Powered by eList eXpress LLC