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

What I still don't grab is the info you would like to define. Classes of 
device aren't defined anywhere, AFAICT, and no two content providers use 
the same ones. How would you state: "this is the representation for 
phones with a stylus"?

Francois.

Jo Rabin wrote:
>>  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:49:42 UTC