- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 08 Oct 2011 16:41:18 +0200
- To: Maciej Stachowiak <mjs@apple.com>
- CC: HTML WG LIST <public-html@w3.org>
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