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 19:01 2002 09 05 +0100, Dave Pawson wrote:
>At 15:00 05/09/2002, Paul Grosso wrote:
>>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. 
>?Or at the documentation level? My tools don't tell me what those
>words mean? tdg does.

If you aren't going to use tag N, why do you need to know what it means/does?

>> 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.
>Except for when I do that odd job that needs another set?

The tool is merely subsetting the list of tags it shows the user
when the user goes to a menu of "tags I can insert here".  But
it's still valid to insert (or have) any tag in the full DTD, and 
you can always click the button on the tool that says "show me all 
tags" instead of just the "most used subset".  (For example, Epic
Editor supports this kind of thing.)

>>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.
>Sorry Paul, I don't see that. Its my head that can't handle it,
>not the tools. Hence the interop issue is a non starter for me.

Suppose your head can only remember the simplified subset.  So what
if your doctype declaration points to the full DTD, all your head
has to handle is the set you're using.  In what way does having lots
of tags in the DTD that you are never going to learn or use give your
head a problem?  If you haven't learned about them and don't use them, 
how can the fact that they're in the DTD bother your head--your head
doesn't even know they are there.

Unless your tool forces the fact of their existence on you by showing
them all to you in some menu.  And I'm saying it doesn't have to.

>>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.
>?Status quo? Seems to me that's how you operate now (TC that is)

Yes, that's what I'm suggesting.


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

Powered by eList eXpress LLC