RE: ACTION-983: same-document reference

Well, I suppose not, but it means that the text needs to change to say that a same document reference in a link element can't be relied upon as an indication that the content is mobile. So we will have to take it out of the list or otehrwsie annotate it.

Jo

> -----Original Message-----
> From: Francois Daoust [mailto:fd@w3.org]
> Sent: 23 June 2009 07:46
> To: Jo Rabin
> Cc: Mobile Web Best Practices Working Group WG
> Subject: 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 09:23:06 UTC