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

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.


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

Powered by eList eXpress LLC