This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: Re: A straw proposal for help topics in DocBook
- To: Norman Walsh <ndw at nwalsh dot com>, docbook at lists dot oasis-open dot org
- Subject: Re: DOCBOOK: Re: A straw proposal for help topics in DocBook
- From: Ed Nixon <ed dot nixon at LynnParkPlace dot org>
- Date: Fri, 19 Oct 2001 08:51:47 -0400
- List-Id: <docbook.lists.oasis-open.org>
- References: <10110181104.aa19676@mammoth.ca.caldera.com>
Comments inline, below.
At 06:48 AM 19/10/2001 -0400, Norman Walsh wrote:
>/ Bob Stayton <bobs@caldera.com> was heard to say:
>| I think Karl's point is that before new elements are added
>| to Docbook, that someone should convince the skeptics that the
Skeptics: perhaps to some it is more an issue of resource and time
utilization. It's a sticky issue because we are not working with
conventional economic constraints or priorities, i.e., this is voluntary
work by and large. So the concern might be expressed thus: should time be
spent on new, perhaps questionable, perhaps highly intrusive and complex
design and development work OR should time be spent on ensuring / improving
the various documentation and support foundations of the current
environment. It's a hard question in the light of, say, promoting and
evangelizing DocBook because both alternatives have potential for wining
new users. The first, the online, hypertext authoring community; the
second, the less than inveterate (but potentially advocacy useful) user
community, e.g., generic business consultants & analysts, project mangers.
>| legitimate needs for generating help output cannot be met
>| using existing elements, role attributes, and stylesheets.
>
>Well, it all depends on how tightly you want to define "cannot be
>met". This is a slippery slope, DocBook doesn't really "need" all
>those inlines, for example, everything could be done with <phrase>
>and some attributes. :-)
Perhaps it's the old trade off between "richness" and "complexity". These
qualities lie on a continuum and are in the eyes of the beholder, dependent
on level, type and duration of experience with the packages. The new Guide
and additional well organized, web-based support material would move the
centre of gravity of this continuum further toward "rich" and away from
"complex". This is a good thing.
><snip>
>
>We could say, "it's technically possible, they oughta learn how to do
>it 'our way'", but I'm reluctant to do that without at least
>considering other options.
Yes. Particularly when the impetus to change may be intrinsic to the person
rather than extrinsic from the organization he or she is working for.
Regards. ...edN
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>