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

Well yes, I agree and pI robably wasn't being clear.

It's an interesting question as to what we mean by device classes, but I 
think you might first have to answer the question of what is a 
distinguishable device type. So while interesting, not in scope, probably.

I think that all I meant was that one could say something like

<link rel="alternate" media="handheld" href="http://example.mobi />
<link rel="alternate" media="screen" href="http://example.mobi />
<meta name="media" content="handheld" />

and that would tell you that the handheld version is at the same URI as 
the desktop version and that this representation is the handheld one.

Jo

On 15/09/2008 15:49, Francois Daoust wrote:
> 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 15:19:01 UTC