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

["Jeremy H. Griffith" <jeremy@omsys.com>]

I've just joined, thanks to Rob's kind invitation, and have 
read up from the archive.  (You can fetch everything so far 
with one email. [1])

On Mon, 1 May 2006 10:43:47 -0700, "Paul Prescod" <paul.prescod@xmetal.com> 
wrote:

>[HELP-RUNTIME-ML] The definition of a UA runtime format that would
>replace the plethora of specific or proprietary ones like JavaHelp,
>Eclipse Help, Apple Help, Oracle Help, MS Compiled Help, MAML etc.

A good idea.  We implemented that idea with our open-source
OmniHelp format [2], which uses [X]HTML, CSS, and Javascript
but no applet, and runs in any browser on any platform.  It
supports what we see as the key OLH features: TOC and IX (both
expanding), Search (indexed, with Booleans), Related (ALinks),
and run-time merging.  We plan to add filters (infotypes) soon.
Skins can be made with pure CSS.  Quite a few of our cutomers
(for Mif2Go) are using it in production now.

>[HELP-INTERCHANGE-ML] The definition of a common intermediate
>(transient) format that could be compiled into all of the specific or
>proprietary UA formats.

Mif2Go is based on a general-purpose document description
language, DCL [3], which we created some years before XML.
If we had to do it again, we might well use XML, though one
advantage of DCL is a really fast binary format as well as
an ASCII format.  However, since Mr. Moore has not been idle,
that's become less important.  We're interested in your HIML 
ideas, which could perhaps be implemented as an XML namespace.

On Mon, 1 May 2006 18:43:17 -0700, "Paul Prescod" 
<paul.prescod@xmetal.com> wrote:

>I represent a vendor of authoring tools so I can guarantee that 
>a UA authoring standard will actually be adopted by someone. 

Same here.  ;-)  We'd be delighted to see a standard to
replace the Tower of Babel we have now for Help.  It would
allow authoring vendors to compete on fullness of features
and ease of creation, rather than offering varying degrees
of brokenness for a dozen Help applications and platforms.

>If representatives of runtime engines are similarly willing to 
>step up and participate then I would love to work with them!

It may be that the only run-time engine needed is a browser.
We favor that over re-inventing basic display methods, as
Sun has done with ... interesting ... results in JavaHelp.
Oracle Help for Java uses a proprietary browser instead...

We'd like to avoid plugins too, but that does impose some
fairly onerous constraints, especially on local data storage
(like bookmarks) and on CSH.  For example, you can't change
CSH topics in a running instance with a second call from the
application AFAIK, which is annoying.  And cookies have their
limits for storage, so annotations are not really possible.

This suggests to us that an open-source Help plugin may
also be needed, and developing the API for that plugin may
be another desirable goal for this group.

Thank you, Paul, for initiating this; and thanks to all
for participating!

-- Jeremy H. Griffith, at Omni Systems Inc.
  <jeremy@omsys.com>  http://www.omsys.com/

[1] Send an empty message to: <user-assistance-discuss-get.1_100@lists.oasis-open.org>
[2] OmniHelp is described at: <http://www.omsys.com/dcl/omnihelp.htm>
[3] DCL is described at: <http://www.omsys.com/dcl/dcl.htm>