Re: HTML Links and Paths

Terry Allen (terry@ora.com)
Sat, 20 May 95 19:18:20 EDT

Murray on Terry:
| > <LINK class="pathone" begin="http://foo">
| > <LINK class="pathtwo" begin="http://goo">
| Actually I think that you meant:
| <LINK class="pathone" REL=begin HREF="http://foo">
| <LINK class="pathtwo" REL=begin HREF="http://goo">

Yes, sorry to be careless.

| > You can have them. How the UA deals with them is another matter.
|
| OK, you are right, you can have them. But before I go
| putting something like this in the proposal, I wonder
| if we could figure out how a UA might deal with this?

Well, if the key is the CLASS att value, the browser might be cued
to respond appropriately by a style sheet, or might engage in dialogue
with the user ("Do you want to follow path PATHONE or PATHTWO?") before
picking up one of the paths. A really dumb browser might fix upon
the first- (or last-) encountered LINK with REL=begin. But if we're
going to have paths, we want to be able to have more than one of them
per docset.

[Imagine that someone constructs a series of paths such that their
intersections mean something; a UA presents the user with a map of
all the paths, his path along any one of them being shown. He
can transfer to another path at an intersection. What content is
presented in that manner?]

| Being able to define and follow paths through a docuverse
| is a key part of the ongoing development of HTML and the WWW
| -- my assertion -- and I think that we need ways to include
| path definitions and relationships within HTML documents
| as well as in related documents which on;y contain path info.

Yes, one should be able to construct the paths by pointing into
the docset. But I'm not saying that that's essential to having
more than one path.

| I'd like to see a real simple processing model and
| an unambiguous UI described. If it is not simple, then
| someone probably won't understand it -- likely me.

Okay. How about this as a straw:

1. If your browser supports LINK REL=BEGIN/NEXT/PREV/END minimally,
(and we harmonize this with PATH/NODE), you either use the first-defined
LINK in which any of these values occurs to set its path functionality
(or last, I don't care, but it ought to be one or the other; what's
better?), and you present the user with the info that there's more than
one path. But if you follow a path, you stay on this one until you reach
either the BEGIN or END.

The browser sorta has to have a FOLLOW PATH button, I'd think. Murray,
did you design anything to handle paths?

Now here's a question about paths in general: when and how do I get off
one? in the course of a session I want to travel along half a dozen
paths, in related and unrelated docsets. Do I automatically lose my
path if I move to an HTML doc that has no LINK info? if I start a
second path and then move BACK BACK BACK to a node in a previous path,
which path am I on? I think this is a separate discussion.

2. One step up: you fix the path by either the first or last value,
but also allow the user to reset the path to some one of the other
values of CLASS, whenever new values occur.

3. If your browser supports LINK REL=BEGIN/NEXT/PREV/END a little better, it
engages the user in dialogue to determine the desired path.

3. If you really want to support paths spiffily, your browser presents
a view of path info as you move along paths or navigate by other means
(I could be just browsing and discover I'm on some interested path
this way). The user always has the opportunity to get onto or off
of a path, or to transfer to another path, and also the information
to understand where the various paths lead. (That might require
more info than we're considering providing here.)

| If it seems worthwhile to develop a thread on this topic,
| please respond with "HTML Links and Paths" as the subject.

your obediant servant.

Regards,

-- 
Terry Allen  (terry@ora.com)   O'Reilly & Associates, Inc.
Editor, Digital Media Group    101 Morris St.
			       Sebastopol, Calif., 95472
occasional column at:  http://gnn.com/meta/imedia/webworks/allen/

A Davenport Group sponsor. For information on the Davenport Group see ftp://ftp.ora.com/pub/davenport/README.html or http://www.ora.com/davenport/README.html