Re: HTML link types - how much must be specified in the standard ?

Albert Lunde (Albert-Lunde@nwu.edu)
Tue, 16 May 95 08:35:27 EDT

> REL values of type 3., on the other hand, can be reasonably pushed off into
> an advisory document, as they require no specific behavioral guarantees of
> an HTML user agent.

I disagree with the apparent suggestion that it's not as important
to standardize REL values that simply define a binary relation
between documents or an attribute of the document pointed to,
but do not require different browser behavior to follow a link.

Having these standardized, with some brief defintions of semantics,
is potentially useful for document indexing tools. It also
allows browsers to implement things like dynamic button bars
based on document structure.

Coming up with a list of static relationships that will
be useful is a "smaller" project than defining the dynamic
relationships but shouldn't be neglected on that account.

We do need some way to distingush between these static relationships
(in the mathematical sense of "relation") and new browser functions
(in the programming language sense of "function"). I'm going
to offer some brainstorms about this problem of notation.

A heirarchical space of REL names or extra SGML attributes to
convey more information is one way to address this (and I'm
not totally opposed to heirarchy, just skeptical about
making it look like a URL when it seems to me to be something
different.)

I also wonder if it might make sense to use a complely different
SGML attribute than REL to define dynamic browser actions.

This would present a clearer picture for implementors; unknown REL and
REV markup could be treated as informational where as unknown
values of this new attribute on <A ...> would indicate that a link
could not be followed. (Also REV makes less sense for dynamic
actions.)

This would require messing with the DTD to add a new attribute
and wouldn't quite fit the general pattern of dealing with
unknown markup. So in a sense, I agree that it is important
to document how we are going to bring in dynamic behavior
early (I just don't want to ignore the standarization of
static relationships.)

A fall-back postion is to try and define a list of REL values
and say "these are static, these are dynamic", but this
fails whenever we want to define a new dynamic action.

There is some attraction to the idea of having a metalanguage
to define this information, but the prospect of specifying it
puts me off.

Another idea is to accept the idea of REL values as a comma
separated list, and have keywords like "ACTIVE" which indicate
deviations from the static relationships model. On the other
hand this means not all combinations make sense and
I'd have to write something like REL="BACK,ACTIVE" instead
of REL=BACK.

If we adopted a heircharcy of REL values, we might adopt the
convention that REL values with no indicated heirarchy could
be safely ignored, while values written with a heirarcical
syntax may indicate a dynamic action. This would mean that,
say REL=NEXT is static while REL="/NEXT" or REL="THREAD/NEXT"
could be dynamic. (Use of slash rather than dot or something
else to indicate heirarchy is fairly arbitrary here.)

-- 
    Albert Lunde                      Albert-Lunde@nwu.edu