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
path.
| This proposed implementation requires the use of REL=Subdocument (already
| proposed in the current version of the HTML+ spec at
| ftp://15.254.100.100/pub/draft-raggett-www-html-00.ps )
| 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>
]>
Our sample document includes the file node1.html by means of the following entity reference. &firstnode;
And after the next included file we can quit. &secondnode; 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: |
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. Regards, -- Terry Allen ([email protected]) Editor, Digital Media Group O'Reilly & Associates, Inc. Sebastopol, Calif., 95472