RE: DOCBOOK: On the size of DocBook...

[Peter Brooks <pbrooks@appliedsemantics.com>]

Just my 2c here - spit on it and throw it in the gutter as you see fit:

Taking Visio as an example of an approach that would work well for me, when
creating a new document the user doesn't get presented with a window
containing all the symbols available. Instead, they pull up the relevant
window (or windows) containing the set (or sets) they need for a particular
type of design task. If they need a symbol that isn't provided by the group
of symbols windows they currently have open, they pull up the relevant
window and use whatever they need.

Dividing up the tags into (hopefully) logical subsets appropriate for a
particular purpose would IMHO make life a lot easier. The problems arise
when trying to decide what those subsets should be and what they should
contain :)

I know that my productivity is degraded when I have to frequently scroll
down through a long list that contains more than I need in order to find
what I'm looking for.

And I'm only using Simplified DocBook...

Peter

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