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

 > Now I see what you mean. I don't like the example as it re-introduces
And then again, I'm sorry to say that I don't much like the idea of

<link rel="alternate" media="screen"
 href="http://example.mobi?media=screen" />

because I think that dereferencing that URI would result in a 301 
redirect to http://example.mobi because that is the canonical URI and 
you would quite definitely want to use that one as a bookmark.

Also although trivial to implement, this doesn't seem to me to be an 
established convention. So I think it would be hard to recommend it as 
"best practice".

Jo


On 15/09/2008 18:01, Francois Daoust wrote:
> Now I see what you mean. I don't like the example as it re-introduces 
> the possibility to understand a "same-document" reference as 
> representing something else than the same representation, but that's not 
> the point here.
> 
> A typical use-case would be: "hey, I'm serving you the screen 
> representation because you've modified the HTTP headers to fake a screen 
> user agent, but I have handheld representations available". And that's 
> an important use-case.
> 
> Again, we could create such a mechanism. I fear it could introduce more 
> complexity than simplicity though (it would have to be a mechanism that 
> complement the already mis-understood Linking mechanism). My personal 
> take on that is along the lines of the TAG Finding I think: it's more 
> reliable to use different URIs, and not that impracticable given the 
> limited number of possibilities.
> 
> For instance, suppose the URI is http://example.mobi, one could define:
> 
> <link rel="alternate" media="handheld" href="http://example.mobi" />
> <link rel="alternate" media="screen" 
> href="http://example.mobi?media=screen" />
> 
> ... which says that current representation is a handheld representation, 
> and that there is a screen representation available at:
>   http://example.mobi?media=screen
> ... I do not really get why this is difficult to implement from a 
> content provider's perspective, especially since the fact that it needs 
> this means it's already playing with content adaptation, which is by far 
> more difficult to achieve.
> 
> 
> Jo Rabin wrote:
>> 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 Tuesday, 16 September 2008 09:39:55 UTC