Re: ACTION-983: same-document reference

Jo Rabin wrote:
> "Oh no!", the lemming says ...
> 
>> [[
>>   the content is HTML and contains <link rel="alternate"
>> media="handheld" href="[same-ref]"/> where [same-ref] is a "Same
>> Document reference" as defined in RFC 3986 section 4.4 [REF]. In
>> particular, an empty href attribute is a "Same Document Reference".
>> ]]
> 
> But this won't work for a multi-serving environment, will it. We are left with only using a vary header in such situations?

That is right. It won't work for a multi-serving environment. That's a 
shame, but we can't change the way the href attribute is understood for 
our own purpose, can we?

Francois.


> 
> Jo
> 
>> -----Original Message-----
>> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
>> Behalf Of Francois Daoust
>> Sent: 22 June 2009 16:43
>> To: Mobile Web Best Practices Working Group WG
>> Subject: ACTION-983: same-document reference
>>
>> Hi,
>>
>> Discussion on "same-document" references started a long time ago when
>> Dom managed to have the group follow his unwise principle that a URI
>> always represents the resource and not a given representation of the
>> resource. This led to the production of a very smart algorithm in the
>> last call version of the guidelines. This was shortly followed by last
>> call comment LC-2009 [1]. The comment pointed us to section 4.4 of
>> RFC3986 "Uniform Resource Identifier (URI): Generic Syntax" [2] that
>> defines the concept of "same-document reference".
>>
>> In particular, it does say:
>> [[
>>     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.
>> ]]
>> ... meaning that a URI that appears in the representation of a resource
>> and that happens to be a same-document reference represents the
>> representation of the resource, and not the resource itself.
>>
>> We blamed Dom. We still had extensive discussions on the topic such as
>> in [3], in particular because it also connects with the ("Oh no!", the
>> Lemming says and explodes) ISSUE-222 [4] and the TAG Finding On Linking
>> Alternative Representations To Enable Discovery And Publishing [5]. The
>> thing is the theory does not entirely match practice and most (all?)
>> browsers do not correctly handle the case when you want to use a
>> canonical URI for bookmarking purpose. Plus there is no true way to
>> define a URI as the canonical URI for a set of representations [6].
>>
>> Whilst this is true, it is not directly related to the definition of a
>> "same-document reference" and does not change its definition either. In
>> short, unless we have good reasons not to, we should stick to the
>> definition of the above-mentioned RFC, and this is exactly what
>> Appendix
>> G.1.4.2 [7] does.
>>
>> However, the first bullet point in section 4.2.9 [8] restricts the
>> possibility of a "Same Document reference" to an empty href attribute.
>> For consistency, the text should rather be:
>> [[
>>   the content is HTML and contains <link rel="alternate"
>> media="handheld" href="[same-ref]"/> where [same-ref] is a "Same
>> Document reference" as defined in RFC 3986 section 4.4 [REF]. In
>> particular, an empty href attribute is a "Same Document Reference".
>> ]]
>>
>> Francois.
>>
>>
>> [1]
>> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-
>> 20080801/2009
>> [2] http://tools.ietf.org/html/rfc3986.html#section-4.4
>> [3] http://lists.w3.org/Archives/Public/public-bpwg-
>> ct/2008Sep/0027.html
>> [4] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/222
>> [5] http://www.w3.org/2001/tag/doc/alternatives-discovery.html
>> [6] http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0096.html
>> [7]
>> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-
>> drafts/Guidelines/090622#sec-use-of-link-element
>> [8]
>> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-
>> drafts/Guidelines/090622#sec-proxy-decision-to-transform
>

Received on Tuesday, 23 June 2009 06:46:31 UTC