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

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

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

Regards DaveP

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

Powered by eList eXpress LLC