Re: REL and REV attributes -- a new RFC?

Craig Hubley (craig@passport.ca)
Wed, 10 May 95 17:59:13 EDT

> > For instance:
> >
> > o REL and REV remain open-ended CDATA strings with the ability
> > for authors to define their own names.
>
> I think that I would lean towards NAMES rather than CDATA,
> but I am willing to be convinced otherwise. I am thinking

I posted a few reasons why they should be stated in URL form: to allow
for lookup of a definition over the network, to keep one binding scheme
for all of the inputs to the behavior of the link, and to be consistent
with other ways that browsers implement complex link behavior (e.g. mailto)

> that it is reasonable to constrain the name space to this
> extent, but not so far as to define a restricted set of values.

Everyone seems to want an open ended list of values, there is some dispute
on how to signal to the author that they are using a 'standard' or non-
standard value. In the URL scheme this is simple, "linkas:html4/new-type"
is clearly a new type defined in html4. If REL="new-type" and the author
has specified that the document is of type HTML4, this can be constructed
but is less reliable than unambiguously stating the exact behavior desired
in one place.

> > o The I-D defines a set of reserved keywords from this open-ended
> > space of names for REL/REV attributes.
>
> Yes.

A URL/URI approach does not require new keywords, although the browser would
have the authority to intercept and interpret certain "linkas:..." types,
thus making them effectively keywords. The only difference is that this
allows for some 'keywords' to be in use in scopes smaller than 'all of HTML'.

> > o Some reserved words are defined for use with document specific
> > toobars/menus while others are defined for specific purposes
>
> I'd like to read a more complete explanation of these points.
> Explain the mechanism through which document-specific toolbars/menus
> will be encoded/generated/taught. What do you mean by "specific purposes"?

Any standard that defines words beyond strict, unambiguous, browser behavior,
is imposing a specific rhetoric of hypertext. In other words, defining the
meaning of 'glossary', 'footnote', etc., when these might imply many different
browser behaviors. Be very aware of crossing this line. Authors will no longer
control the presentation of their documents if they can't decide for themselves
when a footnote is to appear as a floating window or collected at the end
of a section/page. This is the kind of thing that tends to create very heavy
resistance. Browsers can be trusted to do simple interpretation, for online
docs or other such documents.

> > Here is my suggested list for toolbars/menus:
> > (toolbars can be customised with icons via stylesheets)
> >
> > HOME -- defined by browser --
> > BACK "
> > FORWARD "

I assume you mean BACK vs. FORWARD is chronological, since it is 'defined
by the browser'....

> > HOTLIST "
> >
> > TOP
> > UP
> > PREVIOUS
> > NEXT

..and PREVIOUS vs. NEXT is spatial. Very much the opposite of the
dictionary. Sigh. I suppose it is too late for people to relearn 'back'.

> > TOC

Difference between TOC and TOP ?

> > INDEX
> > GLOSSARY
> > HELP -- for help with orientation, not help on topic --
> > BOOKMARK -- for author specified menu, caption via TITLE --

These are the rhetorical marks I was scared of. Is there any behavior
associated with these other than going to a page, or are these just
names with the standard 'goto' semantics ?

> > COPYRIGHT
> > AUTHOR
> > ABSTRACT
> > PUBLISHER
> > DISCLAIMER
> > URC

Fine, these have nice clear semantics, 'thanks' to our friends the lawyers.

> > The other REL values for LINK
> >
> > BANNER -- see HTML3 I-D for explanation --
> > STYLESHEET

OK.

> > Values for use in defining Guided Tours with <A> element.
> > These allow Guided Tours to be defined using HTML, for instance
> > as part of tables of contents, e.g. <A REL=NODE REV=TOC HREF=Chap1.html>...
> >
> > NODE -- implies PREVIOUS/NEXT LINKs for given URI --
> > PATH -- given URI contains <A REL=NODE> links that
> > should be inserted into the guided tour --
> >
> > The browser treats the REL=NODE URIs as forming a sequence of nodes
> > to follow and sets the <LINK REL=PREVIOUS>, NEXT as appropriate for
> > each node as it is visited.

Hmm, getting complex. I can see that this is useful but the *browser* SETS
the REL=?... this is exactly why I suggested that the browser get a URL/URI
and interpret it as they see fit, rather than having it actually change the
strings, just change the place where it looks up the meaning of the string.

-- 
Craig Hubley                Business that runs on knowledge
Craig Hubley & Associates   needs software that runs on the net
mailto:craig@hubley.com     416-778-6136    416-778-1965 FAX
Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5