> Perhaps we need some structuring elements which determine how a
> group of related documents can be sequenced into a form suitable
> for printing, along with a way of automatically generating a table
> of contents, and an index.
If a browser were able to automatically generate a table of contents
(T.O.C.), you'd have all you need to print a book.
Consider FrameMaker. To generate a T.O.C. in Frame, one specifies
which "paragraph formats" (as Frame calls its markup tags) to include
in an automatically generated T.O.C.
If a user were to ask a browser to search for and list a
user-specified set of tags (such as headers), and if the user could
then select which items to include/exclude in the T.O.C., the user
could have his/her own custom book.
But how does the user specify the limits of the search? All the Web?
This raises the spectre of the web-roaming cyberbots discussed
earlier. Or matches to keywords found in headers throughout the Web?
This becomes WAIS-like. Or local nodes only? There's an issue here of
what constitutes a "group of related documents": the author's intent?
Or the reader's interest?
It's interesting to consider that printing a book and searching the
Web might be closely related issues. I've come to believe that a book
is not a document, but rather a point of access to an organized
collection of documents. I'd be happy to elaborate out-of-thread...
>From this point of view, it seems a bad idea to include "structuring
elements" inside documents that tie them together for printing (if
that's what you were suggesting), though there's no harm in
encouraging authors to provide one or more T.O.C.'s (or encouraging
readers to contribute their own T.O.C.'s).
Daniel Kehoe
contributing editor, NeXTWORLD magazine; and co-author,
"Taking the Next Step: The Buyers' Guide to NEXTSTEP Computing"