Re: REL and REV attributes -- a new RFC?

Albert Lunde (Albert-Lunde@nwu.edu)
Fri, 28 Apr 95 09:05:13 EDT

I'd suggest that to clarify the intended meaning of various link
attributes, especially those having to do with navigation, it might
be useful to present some abstract models of document structure
and browser behavior, and refer particular defintions to particular
models. This would make distinctions and relations between
terms more clear.

I think a little terminology from graph theory would help (the
editor might want to look this up, I'm talking from memory)

Hypertext links between documents, and some other relationships
like parent/child relations can be looked at as a directed graph.

In general this graph may _not_ be a tree, but in the case of
parent child relationships we hope it bears some resemplance.

I'd suggest that a lot of our terminology tends to assume it
is dealing with one of several tree-structured hierachies. It
may be simpler for a first-cut to define REL/REV terms as if
we were dealing with a tree, then indicate if we can what
breaks down for general graphs. Some things may make sense
locally within general graphs.

Several hierachies come to mind. Parent-child relationships
in defined within <LINK> define one. (The directed graph
defined by this relationship will most likely be smaller
than that defined by all hypertext jumps in a document because
jumps from a child back to a parent wouldn't be included.)

The URL path hierachy is another. This may or may not
refer to a real filesystem, and may or may not exist
in any but a trivial sense. But this is what relative
URLs are defined in terms of.

Someone else mentioned some terms that might refer to
a threaded news/mail reader ... another graph, though
not trivial to define.

Problems with assumptions about trees may arise if there
are cycles in the graph define by relationships or
perhaps if documents are dynamically generated.

In addition to navagation terms referred to some tree
structure, there seems to be an assumption that an
author may wish to define a locally linear thread that
orders documents for reading or printing, and some
navigation refers to this.

(In the case of a tree with ordering on its children
we also have standard traversals: inorder preorder postorder.)

I'd also point out, when it comes to referring to
browser behavior that there is a differece between
a browser that keeps a history list of all documents
visted and one which keeps a history stack and pops/discards
things from that stack when you return to previously
visted documents.

The meaning of going back/up in the history thus can have
different meanings depending on the implementation.