Change Proposal for ISSUE-170, was: ISSUE-170 rel-uri-valid: Chairs Solicit Proposals

On 2011-09-07 20:05, Maciej Stachowiak wrote:
>
> 'make URIs valid link relations'
>
> Per the decision policy, at this time the chairs would like to solicit volunteers to write Change Proposals.
>
> http://www.w3.org/html/wg/tracker/issues/170
> http://dev.w3.org/html5/decision-policy/decision-policy.html#escalation
>
> If no Change Proposals are written by October 8th, 2011 this issue will be closed without prejudice.
> ...

SUMMARY

The rel attribute for the link element is defined as [1]:

"The types of link indicated (the relationships) are given by the value 
of the rel attribute, which, if present, must have a value that is a set 
of space-separated tokens. The allowed keywords and their meanings are 
defined in a later section. ..."

(where the link for "allowed keywords" leads to the sections describing 
the HTML5-specific relations plus the description of the registry, [6]).

The subsequent text hints at a relation with the HTTP Link header field, 
defined in RFC 5988 [2]:

"HTTP Link: headers, if supported, must be assumed to come before any 
links in the document, in the order that they were given in the HTTP 
entity header. (URLs in these headers are to be processed and resolved 
according to the rules given in the relevant specification; the rules of 
this specification don't apply.) [HTTP] [WEBLINK]"

RFC 5988 allows Registered Relation Types [3] and Extension Relation 
Types [4]. The latter take the form of a URI, and are designed for cases 
where registration isn't needed, for instance when they aren't 
sufficiently generic to require a public short name, or when they won't 
be used outside a specific application.

HTML 5 requires link relations to be registered centrally, which defeats 
the point of having this extensibility point. It would be preferable if 
it was consistent with RFC 5988, not requiring registration of these 
link types.


RATIONALE

Having different rules for links in HTTP header fields, HTML, and other 
markup languages (such as Atom) makes it unnecessary hard to convert 
between formats, and to handle links in a consistent way.

For instance, an Atom feed document using CMIS link relations [5], when 
converted to an HTML representation, will either (1) have to loose the 
link relations or (2) will end up as invalid. (2) could be avoided by 
actually registering the Extension Relation, which conflicts with the 
original choice of choosing that type of link.


DETAILS

In [6], after

"Extensions to the predefined set of link types may be registered in the 
Microformats wiki existing-rel-values page. [MFREL]"

add

"In addition, link types that take the syntactical form of an absolute 
URL MAY be used when public registration isn't desired, such as for 
private use. See Section 4.2 of [WEBLINK] for details with respect to 
comparison."

IMPACT

1. Positive Effects

Consistency with links in HTTP header fields and Atom feeds. Avoids 
having to maintain relation types in the registry which are not intended 
for public use, or only in very specific applications. Avoid misleading 
validation warnings.

2. Negative Effects

None.

3. Conformance Classes Changes

Makes the use of unregistered link relations using absolute URL format 
compliant.

4. Risks

None.


REFERENCES

[1] <http://dev.w3.org/html5/spec/Overview.html#attr-link-rel>
[2] <https://tools.ietf.org/html/rfc5988>
[3] <https://tools.ietf.org/html/rfc5988#section-4.1>
[4] <https://tools.ietf.org/html/rfc5988#section-4.2>
[5] 
<http://docs.oasis-open.org/cmis/CMIS/v1.0/cs01/cmis-spec-v1.0.html#_Toc243905525>
[6] <http://dev.w3.org/html5/spec/Overview.html#other-link-types>

Received on Saturday, 8 October 2011 14:41:50 UTC