Re: Paths, HTML+, SGML

• Mail folder: WWW Talk Jan 94-present
• Next message: dolesa@smtp-gw.spawar.navy.mil: "Solution Found: A/UX & Inline Images (Gifs)"
• Previous message: Thomas R. Bruce: "Cello Beta v.8 Released (longish)"
• In-reply-to: Terry Allen: "Paths, HTML+, SGML"

From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-id: <9401131645.AA25811@manuel.hpl.hp.com>
Subject: Re: Paths, HTML+, SGML
To: terry@ora.com
Date: Thu, 13 Jan 94 16:45:32 GMT
Cc: www-talk@www0.cern.ch
Mailer: Elm [revision: 66.36.1.1]
Content-Length: 2126

> This implies that one can parse the virtual doc by using the SGML
> SUBDOC feature.  To do this in general, in your SGML declaration set 
> SUBDOC to YES n, where n is the "maximum number of subdocuments that
> will be open at any point in the document" (purists please forgive
> me for citing Martin Bryan, *SGML, an Author's Guide,* p. 199,
> instead of the SGML Handbook).  Then set up the nodes to be 
> included as entities with the SUBDOC keyword:

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