I'm sorry that this is taking up so much of everyones time
and patience. I really wish that we could gather in a room
and discuss this -- I think that would be a better way to
conduct this conversation. I am pretty sure that I am not
explaining myself well enough to some of you. I hope to
take another crack at this soon, and I hope that I can do
a better job. I know that at least part of what I am
proposing works because we (SCO) have published or entire
documentation set in HTML (including all man pages) and
provided a Mosaic-based browser with minor modifications
to the user interface to take advantage of five REL values
which are found in every HTML file. Please bear with me
while I try to figure out how to communicate my proposal
and goals more effectively.
In the meantime, I'll try to respond to Bert Bos's most
recent mail...
Bert Bos writes:
> Murray Maloney writes:
> |Bert Bos writes:
> [...]
> |> BIBLIOGRAPHY,... NAVIGATE
> |> No document is just a bibliography or just a table of
> |> contents. Remember this is hypertext, not a database. The user can
> |> be directed to these links with an informal description in
> |> natuaral language.
> |
> |No document is a bibliography? Are you kidding me?
> |
> |And the point is not whether it is possible to direct a
> |human being to the table of contents, there is no argument
> |to that assertion. But would it not be much more useful
> |to a human being to have the user agent's interface present
> |a concurrent view of a table of contents, or at very least
> |an icon which leads directly to it. Most of the popular
> |hypertext systems provide such a mechanism -- WinHelp,
> |OLIAS, scohelp, and DynaText are examples.
>
> I can see why a robot may want to know where to find the bibliography
> and the ToC. But isn't CLASS enough for that? And before you put
> REL=BIBLIOGRAPHY in a link, you have to remember that an HTML document
> cannot be a bibliography (though it may look like one visually). A
> machine readable bibliography will be something like a BibTeX or Refer
> database but then it's no longer human readable.
I am not talking about a machine readable bibliography. Let me
try to explain by way of a scenario...
OK, so here I am staring at an HTML user agent which is displaying
a passage of text -- the subject happens to be electronic publishing
-- and I note that "The Chicago Manual of Style" is mentioned and
higlighted. This is a clue to me -- a human being -- that there
is a hypertext link associated with the citation. That's all I
know at this point.
So I move the mouse pointer over the citation and note that
a URL is presented near the bottom of the window -- OK, it is
a Mosaic-like user agent. I also notice that below (or above,
if you prefer) the URL is a text string that informs me that
the hypertext link is a "Bibliographic entry". That's useful
and timely information to me.
I decide that I would like to see the bibliographic entry for
"The Chicago Manual of Style" and press the mouse button.
A popup window appears -- that's how I would design it --
and I read the entry, noting that it seems to be part of a
fully annotated bibliography.
Wow! This is just what I need, because the material that I
am reading is not what I really need. So, I move the mouse
pointer to the toolbar and click on the icon that says
"Bibliography".
The next thing that I see is a bibliography prepared by the
author of the document that I was reading -- or perhaps a
bibliography somewhere else on the WWW that the author has
simply pointed to -- and I can peruse this bibliography and
glean whatever information I need, perhaps even following
hyperlinks within the bibliography to documents that have been
published on the WWW -- perhaps even the HTML 3.0 spec.
If the citation to "The Chicago Manual of Style" had not
been identified as a bibliographic entry, I would not
have known whether it would lead me to the actual book,
a bibliographic entry for the book, or maybe even a
parenthetical comment by the author about the book.
I would have had to traverse the link, and I might consider
that to be a waste of my valuable time -- I might not
have the time to scan a book, but a bibliographic entry
I have time for.
Without a <LINK REL=BIBLIOGRAPHY ...> entry in the document,
the user agent would not have been able to present a
toolbar icon that said "Bibliography" and the URL to
GET when it was activated.
That's it. I'm not looking for much more than that.
I don't expect REL=BIBLIOGRAPHY to be link to
form-based query mechanism for searching a BibTeX
database. But I am not pre-supposing that it would not.
That is up to the author/publisher to decide --
and I want to provide them with the flexibility to
do it however they see fit. I am not presuming to know
what sorts of advanced bibliographic tools will be available
to them now or in the future.
> GLOSSARY is dubious. The idea is that it is not a document, similar to
> an appendix in a book, but something that actively looks up words in
> the source document which the user doesn't understand. As such it
> requires special behaviour by the browser, but nobody knows yet what a
> glossary will look like. In a way, GLOSSARY is almost like ISINDEX.
What I was imagining is much simpler than that. I want to be able
to highlight a word or phrase and have the HREF point to the actual
definition in a related document. These is simply a glossary --
as in a printed book -- into which there might be any number of
hypertext links from other parts of the same virtual book.
Now I can imagine writing a fairly simple cgi-bin script that
could do what you are suggesting, given the right architecture
and file layout for the virtual book. But that is up to the
author/publisher of the book.
>
> Just as for GLOSSARY, we have no mechanism for INDEX yet, except for
> ISINDEX. But ISINDEX requires server-side action, so we may want to
> think about a client-side index as well.
Actually, we have just published a series of online books
which are fully indexed -- just like a printed book, except
that instead of page numbers we note the heading which
immediately preceded the indexed term.
The magic is all in how we build the HTML documents that
comprise the virtual book.
>
> For BOOKMARK, HOTLIST and NAVIGATE I can see no reason that they be
> treated specially.
Dave will have to address the BOOKMARK and HOTLIST because
I do not fully understand his intentions.
For NAVIGATE, we have an icon on the toolbar which the user
can hit to lead to a page which provides a mini-ToC that
highlights the current location and provides some additional
information about the users current context within the
virtual book -- and thus a small corner of cyber space.
This is currently achieved with a cgi-bin script which reads
information built into each HTML document and builds a
navigation HTML page from the info gleaned.
>
> [...]
> |Please explain biblioentry as URI.
>
> I understand BIBLIOENTRY as the bibliographic data about a
> document. That can be either a database record (in BibTeX, Refer, TEI
> or something else) or a URI. The latter is enough to describe a Web
> document.
Sorry, I still don't get it. How do I use a URI and have the
browser know that the resource/document at the other end
of the link is a bibliographic entry before traversing the link?
>
> [...]
> |> INCLUDE
> |> This is not a hyperlink at all, but a convenient syntactic
> |> variant, to save typing and/or bandwidth. Whether we need this in
> |> HTML is a separate discussion, but if we decide we do, then an
> |> <INCLUDE SRC=...> element seems more appropriate. (Another
> |> possibility is to support SGML entities.)
> |
> |Please explain to Ted Nelson (the man who invented hypertext)
> |that his notion of "transclusion" has no place in a language
> |that purports to be a "hypertext" markup language.
>
> No doubt Ted Nelson has thought long and hard about this, but without
> arguments I won't accept his authority. I'm not against the mechanism
> (though it causes some problems that need to be solved, such as
> parsing the resulting SGML). I just don't think this has the character
> of a hyperlink.
I strongly recommend the seminal work "Literary Machines"
by Theodor Holmes Nelson, Mindful Press, 3020 Bridgeway Suite 295,
Sausalito CA 94925. Mr Nelson's Xanadu Project has yet to be
completed, and some doubt that it ever will, yet his vision
of hypertext has provied inspiration to many of those who
are participating in the online/hypertext publshing community.
Hypertext links are not just links which lead you to another
document (or another location in the same document). A link
is what the name implies -- a connection to another entity.
Transclusion is the notion that a document may include,
by reference, a portion which is not physically included.
This is especially useful when a transcluded document
is subject to regular update. But it will also be useful
as commercialization of the WWW is realized and publishers
can be reimbursed for use of their material via transclusion.
Authors/publishers of derivative works will be able to leverage
material already on the WWW and add value in the process.
>
> [...]
> |> STYLESHEET
> |> Also not a link. The STYLE element can get a SRC attribute
> |> instead.
> |
> |What STYLE element. How is it not a hypertext link?
>
> HTML3's STYLE element. It's not a hyperlink, because the target
> doesn't contain any information by itself. That's why I want to refer
> to it with a SRC attribute (like IMG, FIG, LI, and many others) and
> not with HREF. The obvious place to put the attribute is on the STYLE
> element.
Ah, now I see the distinction that you are making.
I don't agree with it, but I do see it and I see
that there might be some merit in making the distinction
between HREF and SRC. I still consier it to be a
hyperlink, and I also see value in being able to
"link to" it with <A> -- for editing purposes --
as opposed to "linking in" the information by way
of a <LINK>. I also see the merit in using <STYLE>.
[discussion of NODE, PATH and HyTime deferred]
[summary elided]