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 
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 Monday, 15 September 2008 17:02:26 UTC