Re: Hypertext links in HTML

Bert Bos (bert@let.rug.nl)
Wed, 17 May 95 14:55:41 EDT

A short reaction with a short summary at the end:

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.

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.

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.

For BOOKMARK, HOTLIST and NAVIGATE I can see no reason that they be
treated specially.

[...]
|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.

[...]
|> 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.

[...]
|> 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.

|> NODE, PATH
|> The idea of guided tours is appealing, but the mechanisms proposed
|> so far don't seem to catch people's imagination. I understand how
|> NODE and PATH are supposed to work, but I find it difficult to
|> implement. Two other solutions might be: (1) define a new document
|> format "application/hypertour" consisting of a list of URLs; (2)
|> forget about tours and use a (shallow) hierarchical collection
|> instead (TOP, PARENT, CHILD, see above).
|
|I also asked for details of how this would work.

The original idea of NODE and PATH was as follows: when a browser
parses a document, it collects all links with REL=NODE and REL=PATH
and when the result is not empty, it offers the user the opportunity
to read this list in order (for example by redefining the space bar to
mean "get next in list").

The difference between NODE and PATH is that a document that was
linked with REL=PATH is also scanned for links with REL=NODE or
REL=PATH and the resulting list is inserted into the existing list,
immediately after the document itself. Of course, the operation is
recursive.

|> PS. Not even HyTime can type its links, except with a #FIXED attribute
|> in the DTD. Some people are currently trying to get #FIXED changed to
|> #REQUIRED, though.
|
|Of course you can type links with HyTime. This assertion is wrong.

I don't have my copy of HyTime at hand, but aren't `anchroles' #FIXED?

To summarize:

1. Introduce hierarchical collections into the Web by means of
REL=PARENT and REL=CHILD. (As Larry Masinter pointed out, REL=TOP
is not needed.) I can't think of equivalent verbs: `begets'?

2. Use the CLASS attribute for directing UAs to bibliography, ToC,
etc. but don't standardize the possible values.

3. Use the BANNER element instead of the REL=BANNER attribute.

4. Use the STYLE element instead of the REL=STYLE attribute.

5. COPYRIGHT, AUTHOR (MADE), etc. can be seen as meta-info, but then
they aren't links; maybe new elements.

6. For the future: Do we need new mechanisms for glossary, index, and
guided tour and if so, what will they be?

Bert

-- 
                          Bert Bos                      Alfa-informatica
                 <bert@let.rug.nl>           Rijksuniversiteit Groningen
    <http://www.let.rug.nl/~bert/>     Postbus 716, NL-9700 AS GRONINGEN