RE: [user-assistance-discuss] Clarifying Our Goals

["Paul Prescod" <paul.prescod@xmetal.com>]

1. 

Here is the problem of specific interest to me: existing single sourcing
languages do not have complete coverage of the features available in
mainstream help outputs. I would like to understand which features users
miss most (if any) and determine how to extend those languages to cover
those features. I could see those extensions being expressed as a
DocBook customization and/or DITA domain. If there exists consensus on
this problem statement then we might define those requirements and punt
them to the appropriate other groups for incorporation, or we might
stick around and define the customization/domain here.

2. 

Of secondary interest to me is an interchange language that would make
it easier for help generating tools to target the plethora of help
runtimes. 

But given that the majority of the burden of supporting those runtimes
falls on the shoulder of a few HATT and XML vendors, I would not be
surprised if such a standard would sit on a shelf, ignored by the help
runtime vendors. If you are the inventor of a Help format specific to a
runtime engine, you might see a standard as imposing on your creativity
and homogenizing your software.

The plethora of help formats is a problem (not the main problem I am
interested in, but a problem nevertheless) because authors need to do an
exorbitant amount of research to determine whether they can get from A
to B. "Can I get from DocBook to AppleHelp through the DocBook XSLs?",
"from DITA to Oracle Help through the DITA Toolkit?", "from Word to
JavaHelp through WebWorks"? "from FrameMaker to Eclipse Help using
MIF2GO (as of today the answer is yes!)" etc. Content authors want to
know that the answer is always Yes, as opposed to having a huge matrix
with some fields filled in "Yes", some "No" and others "depends on what
you need". 

Nevertheless, there are some market segments that just resist
standardization (video codecs anyone?) and I suspect that this may be
one of them. So I won't push unless I hear from some help runtime
creators who feel that there is a problem and feel motivated to solve
it. The workaround is just tons and tons of code that fills in the
matrix. There are already megabytes of this code in existence so the
situation is tolerable.

===

These are my goals, but I opened up the floor to other discussions
specifically because I want to hear what other people perceive as
issues.

> -----Original Message-----
> From: Peter Meyer [mailto:pmeyer@elkera.com.au] 
> Sent: Tuesday, May 02, 2006 3:44 PM
> To: user-assistance-discuss@lists.oasis-open.org
> Subject: RE: [user-assistance-discuss] Clarifying Our Goals
> 
> Paul,
> 
> It would help me if I had a better understanding of the 
> reason why you have initiated this list. The list of possible 
> goals is quite extensive and I doubt we would set out to 
> achieve them all in one process.
> 
> What do you see as "the problem" that lead you to start this 
> list? What would be a successful result for you? 
> 
> I can see your reference to a "plethora of ... formats" but 
> these are promoted by different vendors. Do your plans 
> require participation of those vendors so they agree to give 
> up their formats or do you envisage developing something and 
> hoping that it may be adopted over time?
> If the plethora of help formats is the problem, why is that a problem?
> Presumably, if we start from a suitably designed model, we 
> can generate any of them plus any others that come along.
> 
> Peter Meyer
> 
> Elkera Pty Limited (ACN 092 447 428)
> Email: pmeyer@elkera.com
> Ph: +61 2 8440 6900 * Fax: +61 2 8440 6988
> Skype: pwrmeyer
> http://www.elkera.com
>