Thanks for the explanation of how to do this. I'm don't expect that
web browsers would bother with this though. Instead the path document
is kept in a cache and searched when the user clicks Forward (or Next) or
whatever (you might want the browser to read ahead, see below).
> Now the nodes may include anything, from GIFs to (shudder) RTF
> to full HTML instances (complete with HTML, HEAD, and BODY tags),
> to HTML fragments, such as:
Thats the idea. There is quite a bit of interest in using the web
to view scanned images of paper documents. The path (or tour)
mechanism would support this nicely. There is no need to show the
HTML node containing the path unless the user starts with it, since
you can use the LINK element passed via an HTTP header to point
to the path (REL=Path).
> Is the TITLE of a subdoc'd node to be suppressed, for example?
You might want to design the browser to do read ahead along the path
and load the titles into a menu. A shortcut is to specify the title
in the link with the TITLE attribute.
> I'm also unclear about how a REL=path is to be displayed,
> as opposed to a subdocument. Are paths to be indicated as
> anchors? And how does that square with the following?
If you are viewing the document containing the anchor with REL=path
then the anchor works exactly as normal, so that clicking it takes
you to the document that specifies the subpath. The beauty of this
scheme is that paths are also ordinary HTML and can be viewed in
the same way as normal documents. Anchors with REL=Subdocument
or REL=Path work in the normal way, except when being interpreted
as a path specification for another document.
Dave Raggett