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

Jo Rabin wrote:
> 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).

Actually, I had "classes of representation" in mind when I wrote "for 
each representation". The limitation I was thinking about is not the 
impracticality to have a separate URI for each representation but the 
limited number of media descriptors available:
http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-media-descriptors

Even when one considers variations introduced by the potential use of 
CSS media queries there into account (not recommended yet, he adds), 
we're still talking about classes of representation. There is no 
existing mechanism to refine classes of representations to an arbitrary 
level (e.g. to say "that's the representation for Device A, Device B, 
Device C and Device D, but not for Device E").

POWDER could be a way to allow the classes of devices to be publicly 
advertised to the CT-proxy in the future. For the time being, I don't 
really see the need to answer the question, and think we should restrict 
ourselves to this class-of-device-specific URI. Was your point to 
explicitly mention that we're talking about classes of representations?


> 
> 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.

We probably could. Sticking to Link elements allows us to hope for the 
reintroduction of the Link HTTP header for non-HTML content though. 
Anyway, there would be no other way if we really want to go down that route.


As a side note, I'm not sure what a CT-proxy could do if it had the 
possibility to retrieve the description of classes used by a server.

If the message is: "I specifically tailored this page for a Motorola 
RAZR2 V9, no need to transform it", then a Cache-Control: no-transform 
directive is probably the most efficient way to say so.

If the message is: "I tailored this page for Motorola RAZR devices. The 
user experience may be further improved based on nuances between the 
different models, but I don't know anything about them", then a Link 
element with a media attribute set to "handheld" says the same thing, 
and leave the door opened for CT-proxies that really think they can 
improve the UX.

A potentially useful use case is "This is the default handheld 
representation. I don't know anything about the Nokia N95, but I have a 
Nokia N70 representation available", where the CT-proxy could then serve 
the Nokia N70 version to the Nokia N95. I think that's a good point but 
that it's only indirectly linked to Content Transformation. What's 
missing here is a way for a User Agent to say "I'm X, and I'm close to Y 
and Z in features", and more generically means for user agents to 
describe their features, and the user's context.

Francois.


> 
> 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 14:31:46 UTC