LC-2009, LC-2010, LC-2011: Link element

Last call comments:
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2009
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2010
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2011

In short:
We got it all wrong. Per RFC 3986 section 4.4, a "same-document" 
reference "is defined to be within the same entity (representation, 
document, or message) as the reference". This means a "same-document" 
reference identifies the current representation of a resource and not 
the resource itself. The presence of a fragment identifier in a 
reference does not affect the fact that it is or not a "same-document" 
reference.


A more complete extract from RFC 3986 reads as follow:
[[
    When a URI reference refers to a URI that is, aside from its fragment
    component (if any), identical to the base URI (Section 5.1), that
    reference is called a "same-document" reference.  The most frequent
    examples of same-document references are relative references that are
    empty or include only the number sign ("#") separator followed by a
    fragment identifier.

    When a same-document reference is dereferenced for a retrieval
    action, the target of that reference is defined to be within the same
    entity (representation, document, or message) as the reference;
    therefore, a dereference should not result in a new retrieval action.
]]
http://www.ietf.org/rfc/rfc3986.txt


This has two consequences:
1/ Our super-smart idea to use fragment identifiers to represent a 
"same-document" reference now is a super-useless idea. We should simply 
forget about it. No big deal. The important fact is that it can be done, 
using either an empty href attribute or the underlying resource's URI.

2/ There is no way for a Content Provider to say: although you're 
currently having a look at the desktop representation of this resource, 
I have a handheld representation available at the very same address that 
I would be happy to return if only I understood that you are a handheld 
device. This use case is not the most important one, which is to 
advertise the fact that the current representation is intended for 
handheld devices (point 1/ above in other words). The only thing we may 
emphasize here is that, as suggested in the TAG finding [1], 
representation-specific URIS should be created to be able to link to 
them from another representation.

To replace the second and third paragraphs in section 4.2.3.2 Indication 
of Intended Presentation Media Type of Representation as well as the 
first Note, I suggest the following:

[[
In HTML content, servers SHOULD indicate the medium for which the 
representation is intended by including a LINK element identifying in 
its MEDIA attribute the target presentation media types of this 
representation and setting the HREF attribute to the URI of the document 
being served. The HREF attribute may be left empty since it is a valid 
relative reference to the document being served.

In addition it SHOULD include LINK elements identifying the target 
presentation media types of other available representations by setting 
the MEDIA attribute to indicate those representations and the HREF 
attribute to the URI of the other representations.

Note: for clarity, it is emphasized that specific URIs need to be 
defined for each representation to use the linking mechanism described 
in the previous sentence [ref to the TAG finding]
]]

Francois.


[1] http://www.w3.org/2001/tag/doc/alternatives-discovery.html#id2261672

Received on Monday, 15 September 2008 12:45:43 UTC