If three -- i.e. more than zero -- then the door is open.
>
> We're trying to define relations between hypertext pages. Hypertext is
> the informal knowledge representation format par excellence and it
> would therefore be strange to straightjacket it into a formal
> relational algebra.
Try telling that to the HyTime committee or Ted Nelson.
>
> In fact, since hypertext is read by human beings rather than machines,
> the number of relations must be very small and must fit a simple model
> of inter-document relations. Apart from the flat web of pages that we
> have now, I can think of only one other model: a hierarchical
> collection (cf. Hyper-G).
Read by human beings? Surely hypertext is intended to be
read and interpolated by machines. Surely there is value
in providing those machines with meta-information which will
allow them to serve their human masters better. Surely there
must be support mechanisms for flat as well as hierarchical
collections of information. How about other models?
>
> Of course, I don't want to forbid people from collecting pages with
> the help of robots, but that can be easily achieved with either the
> notion of a hierarchical collection (see below) or with proprietary
> values for CLASS.
>
> So, what remains of Murray's list? Not much. Sorry, Murray:-).
Not surprisingly, I don't see the humor.
>
> TOP, PARENT, CHILD
> I would like to keep these, since they constitute a useful
> enrichment of the currently rather flat web. They introduce the
> concept of a hierarchical collection, something that, I think,
> people have little trouble grasping. A browser could follow TOP or
> PARENT links and show a tree diagram of CHILD links, to aid the
> user in navigation. (cf. Hyper-G's `Harmony' browser, except that
> the parent-child relations are now distributed over the documents
> and not kept in a central database.)
Good. I am glad that you see the merit in these.
>
> The rest is not needed:
>
> MADE
> It is unfortunate that this value is already widely used, since it
> doesn't link two documents, but provides meta-information. It
> should have been a separate element or part of <META>.
It might link two documents (a home page) or it might link two objects
-- that is if can think of a person (via an email address) as an object.
>
> HOME, BACK, FORWARD
> A document has no business trying to link to these. There is no
> way a document can assign a meaning to the document that the user
> (or robot) just left. For an applet this would be a different
> matter; one expects an applet to have access to most of the
> functions of the browser.
Thanks, you have made my point. As my list indicates, these are
reserved keywords which have no meaning to a browser.
>
> 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.
>
> BEGIN,... NEXT
> These can again be handled informally. The BANNER area of HTML3
> can help to keep the links in a non-scrolling region.
Sure they can, but why continue to impose such limits?
>
> ARTWORK,... THESIS
> A document can type itself (using CLASS on the BODY tag, for
> example), but there is no need for a hyperlink to type its
> target. In hypertext there are no books or journals, except that
> some pages may have the character of such a thing. The type of
> thing can be communicated to the user informally by the FIG or A
> element.
While I would agree that there may be less advantage in knowing
the CLASS of a target, I do not agree that such knowledge is
without merit or application. More importantly, I do not agree
that collections (1 or more objects) of hypertext objects cannot
be books or journals or theses. What is the point in abandoning
these distinctions simply because the organization and delivery
of the information has taken a hypertext form?
>
> ABSTRACT, BIBLIOENTRY, CITATION, DEFINITION
> Can be done informally (btw. in Web, the biblioentry is simply a
> URI, isn't it?)
Agian, yes they can. But why not provide such knowledge?
Please explain biblioentry as URI.
>
> FOOTNOTE
> (Foot)notes are links to documents that are so short and specific
> that they are better embedded in the main text itself. HTML3 has
> the FN element for this.
Please. Shouldn't authors/publishers make those decisions
for themselves?
>
> 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.
>
> COPYRIGHT,... URC
> Meta-info belongs in the META tag. If, on the other hand, the info
> is meant for human consumption, then an ordinary, informal A tag
> is good enough.
Yes, it is good enough if all you want to do is include a hotspot
in your text. For real publishing on the WWW, it would be nice
to be able to use <LINK REL=COPYRIGHT HREF=COPYRIGHT.html> and
have the UA provide an icon in a toolbar.
>
> BANNER
> Like INCLUDE, this is not a link. HTML3 has a BANNER element,
> which can be used for this. The syntax can vary, maybe use INCLUDE
> inside BANNER, or add a SRC attribute to BANNER.
I don't like banner because it is a specal case of INCLUDE.
I would rather see usage such as <BANNER> <A REL=INCLUDE ...> </>
>
> STYLESHEET
> Also not a link. The STYLE element can get a SRC attribute
> instead.
What STYLE element. How is it not a hypertext link?
>
> 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.
>
>
> Bert
>
>
> 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.
===========================================================================
---------------------------------------------------------------------------
Murray C. Maloney Internet: murray@sco.com
Technical Publications Writer/Architect Uucp: ...uunet!sco!murray
SCO Canada, Inc. My Phone: (416) 960-4031
130 Bloor Street West, 10th Floor Fax: (416) 922-2704
Toronto, Ontario, Canada M5S 1N5 SCO Phone: (416) 922-1937
===========================================================================
Disclaimer: I'm speaking for myself. 'T ain't nobody else to blame but me.
---------------------------------------------------------------------------
Sponsor member of Davenport Group Member of IETF HTML Working Group
===========================================================================