Re: [Scrollkeeper-devel] Re: help URI schemes

[Dan Mueth <d-mueth uchicago edu>]

On Thu, 27 Sep 2001, David Merrill wrote:

> On Thu, Sep 27, 2001 at 01:57:07PM -0400, Alexander Kirillov wrote:
> >
> >
> > > >
> > > > 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?
> >
> > The obvious idea would be for every application, add to OMF one more
> > field, "identifier" and try to keep it unique. For application
> > manuals, it should probably be the same as binary name: for Nautilus,
> > "id" should be "nautilus". Thus, GNOME cd player will have identifier
> > "gtcd" while for KDE player, it is "kscd". This almost guarantees
> > uniqueness. As for different formats/versions/languages - the help
> > browser must have some built in (probably configurable) preferences:
> > e.g., use the language of "locale", latest version, etc.
>
> What about program-name-1.1.1 so both name and version are extractable
> directly?

One of the primary needs for the URI is so that documents can cross
reference each other.  If the docs for program-a-1.0 references the docs
for program-b-1.0 and the user upgrades to program-b-1.1 without updating
program-a, then the documentation will break.  So, having a very generic
URI is more useful than a specific URI.  Similarly, I don't think we want
to use a URN for this purpose, as I believe a URN is the limit of complete
specificity including locale, format, etc. except for physical location of
the file.

I do like the idea of URN's, but I haven't figured out how they can fit
into ScrollKeeper.  They may be valuable when ScrollKeeper becomes
network-enabled and has to locate remote documents.

Dan