Re: help URI schemes [was: Re: gnome-help: uris]

[David Merrill <david lupercalia net>]

On Wed, Sep 26, 2001 at 01:59:17AM -0500, Dan Mueth wrote:
> 
> [cc'ing scrollkeeper-devel, since this is more about scrollkeeper than
> GNOME specifically]
> 
> On Sat, 22 Sep 2001, David Merrill wrote:
> 
> > On Sun, Sep 23, 2001 at 07:00:15AM +0800, Malcolm Tredinnick wrote:
> > > Other help browsers and document viewers which are more tightly tied to
> > > GNOME will also be able able to parse the DocBook XML and _will_
> > > understand the "ghelp://" or "gnome-help://" or whatever-it-is-this-
> > > month scheme.
> >
> > What benefit do you gain from using gnome-help:// instead of http://?
> > I guess I just fail to see any advantage to using a gnome-specific
> > url. The whole point of ScrollKeeper was to build a unified and
> > consistent database rather than more of the hodgepodge we have today.
> > Let's not create more hodgepodge now that we have a chance to do it
> > cleanly and standards-based.
> 
> I think we need a special URI scheme since we need to effectively separate
> the namespace and provide a special resolution system.  For example, the
> Gnumeric Manual needs to link to the GFDL DocBook doc.  However, the GFDL
> doc was shipped with gnome-core, so the gnumeric package doesn't know the
> path to the GFDL file or its format.  The link is done as "ghelp:gfdl" and
> then something (right now it is a combination of gnome-libs and gnome-vfs
> I believe) resolves the full path to the GFDL file (which may be in SGML,
> XML, or HTML BTW), including any target.

Then maybe the approach to take is to to with a URN rather than a URL?
The whole point of a URN is that it is not location specific, which
means the help browser (or consumer of ScrollKeeper, whoever that
might be) would be able to resolve the URN and location the resource
from some other location.

Unfortunately URNs aren't as well known as URLs, and obtaining and
defining a namespace is a big job, potentially.

In the longer term, we should look at newer XML functionality such as
XLink, XPath and XPointer, which all attempt to resolve these issues.

> > > My understanding is that ScrollKeeper stores meta-information about
> > > documents in a non-application-specific fashion. The problem you are
> > > running into is that web browsers need to be set up especially to
> > > understand a certain type of valid URI. You can handle that (nicely, in
> > > my view) with the dynamic rewrite above and leave the ghelp:// reference
> > > there for those applications which can handle it differently.
> >
> > No, there won't be any applications which can handle it differently.
> > We'll all be handling it the same, but we'll also all be handling
> > kde's format and regular http:// format as well. So each of us will
> > have three blocks of code instead of one. It's extra effort for
> > everyone with no benefit to anyone. It's ugly.
> >
> > If you can come up with some real benefit of using gnome-help://, then
> > we should *all* use that format -- but just help:// please. :-)
> 
> I think we have a need for a special help URI scheme.  I would also like
> to get away from a proliferation of help schemes and come up with a single
> (good) help:// scheme which we all share.  This would make things simpler
> in the long term.  We do have to handle a few interesting problems though.
> eg: Does "help://cdplayer" give you the GNOME cd player application or the
> KDE cd player application, or neither?  How do you handle multiple
> documents with the same URI (eg. different versions, languages, formats,
> etc. of a given document)? How do you handle targets for both HTML and XML
> documents at the same time?

I'll have to go reread the appropriate RFC to be sure, but I don't
think that kind of URI is provided for in the spec. That's why I want
to look at a URN, which does allow for `custom' applications.

> I think we can come up with reasonable answers to these questions.  Then
> it is just a matter of adding a new element or attribute to the OMF and a
> bit of code to ScrollKeeper to do the URI resolution.
> 
> I'd be particularly interested to hear opinions from the KDE folks.

Yes, this is a global issue. It's also, unfortunately, going to be a
sticky one.

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                   david lupercalia net
Collection Editor & Coordinator            http://www.linuxdoc.org

The number of error messages we put in front of people is a tragedy.
	--David Cole, general manager of Microsoft's consumer division
	  (The Register, 09-02-99)