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

Well, as we noted to the TAG it's impractical, in general, to have a 
separate URI for each representation - more practical to deal with 
classes of representation and multi-serve within that if necessary. But 
this still begs the question of how to differentiate representations 
within the class-of-device-specific URI (like .mobi, just for instance).

I wonder if there is a way we can use meta elements and Dublin Core 
"Instance of" stuff to denote this? I'm afraid I don't know much about 
Dublin Core.

Jo


On 15/09/2008 13:45, Francois Daoust wrote:
> 
> 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 13:30:50 UTC