I suggest that the following be added to define how to handle these 'author's'
REL values. This would not prevent us from suggesting a list of such values,
just clarify the behavior expected, and suggest REL value naming schemes that
would avoid conflict:
(insert this after the list of standard values:)
TREATMENT OF NON-STANDARD (EXPERIMENTAL) REL VALUES
"All other REL values are considered documentary or advisory. The exact behavior
of the user agent is not defined, but documents will expect the default behavior
of jumping to the given HREF and should be interpreted in a reasonable manner.
"Any string is acceptable as a REL value. User agents which do not recognize a
given REL value are expected to behave as if no REL value had been specified at
all, i.e. jump to the given HREF, if any, or do nothing if no HREF is specified.
Under no circumstances should a user agent visibly fail due to an unrecognized
REL value.
"To support experimentation with link relationships, and avoid name conflicts,
authors (who define relationships) and user agent developers (who determine
their exact behavior) are encouraged to adopt naming conventions that reduce
the likelihood of a browser interpreting a link in an unreasonable fashion.
"It is strongly suggested that a prefix, either "X-" (for "experimental) or
a vendor- or authoring-community-specific name (e.g. "SCOnav-", "legal-")
be used to ensure that link names do not conflict. The HTML standard does
not specify any default nor any means of resolving the behavior to assign
to such nonstandard names. The prefixes "HTML-", "HTML3-", "SGML-", "ISO-"
are discouraged, as are other names which imply formal standardization of
the link names. Authors and vendors are encouraged to collaborate in order
to standardize application- or community- specific sets of link names, and to
enforce their consistency through a social, rather than formal standards,
process. Use of prefixes may be enforced at a later time if this process fails."
To allow us to specify an RFC full of 'recommended' documentary values such
as the ones you specified, the standard might include the following note:
"Other, non-prefixed, REL values may be standardized in HTML at a later date.
The following keywords are assumed to be reserved: ....
OR
"Use of non-prefixed REL values should be confined to those defined in RFCxxx.
Any or all of these may be included in the HTML standard at a later date. Use
of these values should be understood to be experimental and subject to the risk
that the 'expected behavior' may change as usage and user agent behavior evolves"
NOTE on this thread:
Treatment of non-standard values is a separate issue from that of the behavior
of standard values, or the need to define such values directly in the standard.
Therefore I have posted separately on the other issues. This debate is up to
130 messages in the past couple of weeks, so some separation of concerns might
help. If you disagree, feel free to post whatever you want, wherever you want,
but it seems to me that different groups are interested in each problem and
that each problem (means/level of standardization, behavior of standard values,
and treatment of nonstandard values) can be resolved without reference to each
other.
--
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