[Message with no subject]

redback!jimmc@eskimo.com (Jim McBeath)
Date: Tue, 1 Feb 94 09:47:16 PST
From: redback!jimmc@eskimo.com (Jim McBeath)
Message-id: <9402011747.AA16330@redback.>
To: forman@cs.washington.edu
Cc: www-talk@www0.cern.ch
Re: PATHs (was: Comments on HTML+ Request For Comments)
In-reply-to: <199402010459.UAA17295@hake.cs.washington.edu>
Content-Length: 1725

> 1. LINKS:
>  The proposed attributes NEXT, PREV, and PARENT seem like a good idea.
>  I have a suggestion to make these more flexible.
>
>  Problem: The proposed attributes don't work with page sharing.  If you
>  write a linked document and insert meaningful NEXT fields, I can't re-use
>  one of your pages (without copying it manually), because I want a different
>  NEXT pointer.  This problem also surfaces when authors want to put multiple
>  organizations on the pages of a document, e.g. cronological or by subject.
>
>  Solution: To allow page sharing, let the *parent* document specify a *list*
>  of links, then NEXT and PREV depend on how you got to that document.  The
>  list can simply be formed from all the hyperlinks in the parent document,
>  i.e. we don't need a new HTML mechanism.  But we might want a new mechanism
>  to 1) encourage browsers to implement this, and 2) let authors have
>  incidental links that are not part of the sequence of pages. 
>  (Perhaps the parent could even specify a *tree* of links, to override
>  deeper levels in the document tree.  Dubious.)

Dave Raggett and I came up with a proposal for a mechanism we called PATHs
which deals with this issue in much the way you suggest.  It is based on adding
two new link values to the REL attribute: Node and Path.  This proposal was
posted to www-talk on January 10 (with "Subdocument" used instead of "Node"
in that posting).

You can access that posting from the stanford www-talk archives at

    http://gummo.stanford.edu/html/hypermail/www-talk-1994q1.messages/125.html

There seemed to be little disagreement about the proposal.  I believe Dave
was planning on adding it to the HTML+ spec.

-Jim McBeath
jimmc@eskimo.com