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

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

Yes, but as you point out there doesn't seem to be a way to say, using 
the link headers alone, what we want to say. If we could use meta to say 
this is the representation for that device (class) then I think it would 
be a step forward.

Jo

On 15/09/2008 15:20, Francois Daoust wrote:
> 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:29 UTC