Revised change proposal for ISSUE-170, Re: Change Proposal for ISSUE-170, was: ISSUE-170 rel-uri-valid: Chairs Solicit Proposals

On 2011-10-13 19:40, Julian Reschke wrote:
 > ...

This revision steals some text from Henri's version (including the 
removal of the reference to RFC 5988 for comparison), and also restricts 
the values to US-ASCII ("URI" in RFC 5988 does that, while "absolute 
URL" in HTML5 does not -- another case where deviating from standard 
terminology has caused confusion).

-- snip --

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

"Additionally, absolute URLs that do not contain any non-ASCII 
characters, nor characters in the range U+0041 (LATIN CAPITAL LETTER A) 
through U+005A (LATIN CAPITAL LETTER Z) (inclusive), may be used as link 
types."

Change

"...whereas values marked as "discontinued" or not listed in either this 
specification or on the aforementioned page must be rejected as invalid."

to

"...whereas values marked as "discontinued" or values not containing a 
U+003A COLON character but not listed in either this specification or on 
the aforementioned page must be rejected as invalid."

After the sentence add:

"The remaining values must be accepted as valid it they are absolute 
URLs containing US-ASCII characters only and rejected otherwise.

Note: Even URL-valued link types are compared ASCII-case-insensitively. 
Validators might choose to warn about characters U+0041 (LATIN CAPITAL 
LETTER A) through U+005A (LATIN CAPITAL LETTER Z) (inclusive) in the 
pre-case-folded form of link types that contain a colon."

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 Sunday, 16 October 2011 18:51:01 UTC