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

Murray Maloney (murray@sco.COM)
Wed, 10 May 95 12:38:55 EDT


I'm back! Sorry for not getting back
to the list last week as promised,
but the offsite that I was attending
did not provide adequate facilities
for me to login and do mail.

I have permission to work on the I-D for
REL and REV link types from my management.

Over 90% of what Dave outlines below is where
I was intending to go with this, so I don't
have any problems complying with Dave's request.

Within the remaining 10% are minor issues which
I may just need a bit of time to sort through,
and details like the names of some of Dave's
proposed tokens -- SCO has used other names,
like "contents" and "navigate" in place of "ToC"
and "help".

I am trying to synthesize the ton of mail that this
subject has generated -- I'm glad that there is interest
-- and will share my thoughts with y'all very soon.
I would like to have an opportunity to think this through
and talk it over with a few people.


> Murray volunteers to write an I-D on reserved words for REL/REV:
> > What say you?
> I have been pushing for acceptance of document specific toolbars
> based on LINK for some time. Can we take on board these ideas as
> expressed in the HTML3 I-D?
> If Murray provide the document in HTML form, I will reference it
> from the online HTMl3 document files, otherwise, I would like to
> continue to cover this material in the HTML3 document.
> 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
that it is reasonable to constrain the name space to this
extent, but not so far as to define a restricted set of values.
> o The I-D defines a set of reserved keywords from this open-ended
> space of names for REL/REV attributes.

> 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"?

I think that you might mean that there are some general purpose
REL and REV values, like "previous" and "next" that one might
expect to appear on the browser's main tool bar at all times,
being stippled when not applicable.
> o Some reserved words are held back for future definition

For example?
> Here is my suggested list for toolbars/menus:
> (toolbars can be customised with icons via stylesheets)
> HOME -- defined by browser --
> BACK "
> UP
> HELP -- for help with orientation, not help on topic --
> BOOKMARK -- for author specified menu, caption via TITLE --
> The other REL values for LINK
> BANNER -- see HTML3 I-D for explanation --
> 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.
> -- Dave Raggett <> url =
> Hewlett Packard Laboratories, Filton Road, | tel: +44 117 922 8046
> Bristol BS12 6QZ, United Kingdom | fax: +44 117 922 8924