Paths, HTML+, SGML

Terry Allen <>
Message-id: <>
From: Terry Allen <>
Date: Thu, 13 Jan 1994 07:48:04 PST
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
Subject: Paths, HTML+, SGML
Content-Length: 3863
| Date: Mon, 10 Jan 94 12:22:32 PST
| From: redback! (Jim McBeath)
| To:
| Subject: PATHs in HTML

I think this is a fine idea; I have a few questions about how to 
handle the large virtual document that results from following
a path.

| [various omitted passim]
| The requirements for paths:
| 1. A path must be able to include nodes for which the user creating the path
|    has only read access; therefore, it must be possible to define a path
|    which includes nodes in which no path information resides, including
|    non-HTML nodes.

Note that means SGML and non-SGML formats may be combined in the same

| This proposed implementation requires the use of REL=Subdocument (already
| proposed in the current version of the HTML+ spec at
| )
| plus one additional enhancemnt:
| 	Add "Path" to the set of legal REL values.

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:
<!DOCTYPE html SYSTEM "html.dtd" [
<!entity firstnode system "node1.html" SUBDOC>
<!entity secondnode system "node2.html" SUBDOC>
<html><head><TITLE>Title of Initial Document</title></head><body>
<P>Our sample document includes the file node1.html by means
of the following entity reference.
<P>And after the next included file we can quit.

Presumably, browsers can do more or less this same thing
in their own ways.  Note that subdocuments can have their
own DOCTYPE lines (document type declarations).  And you
could retrieve all the nodes, making local copies, and 
parse the collection together.

However, in the example given, subdocuments are included within 
a list:

| An example of an HTML node which defines a single path:
|         <H1>my path</H1>
|         This is a path of things I've found useful.
|         <DL>
|           <DT> <A HREF="node1" REL="Subdocument">label1</A>
|           <DD> a summary
|           <DT> <A HREF="path2" REL="Path">label2</A>
|           <DD> a summary
|           <DT> <A HREF="node3" REL="Subdocument">label3</A>
|           <DD> a summary
|         </DL>
| This path includes node1, followed by all of the nodes defined in path2,
| followed by node3.

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:

<!DOCTYPE p system "html.dtd">
<P>Just a para to stick in somewhere.

I can see inserting nodes such as this in a DL, but how are 
full documents to be displayed?  One is indicating some 
semantic relationship among the parts here, but what is it?
Is the TITLE of a subdoc'd node to be suppressed, for example?

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?

| Given this capability, I could define a path to print out my entire
| Users Manual, and (just as important) to allow me to search through
| the contents of the entire manual with a single command.
| I could then define other, specialized paths that went through different
| pieces of the manual in another order, for people who wanted to learn
| about a particular subject.

I want to be able to do this; I just want to understand the proposed
mechanism better.


Terry Allen  (
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472