- From: Francois Daoust <fd@w3.org>
- Date: Mon, 22 Jun 2009 18:03:05 +0200
- To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
I forgot to talk about the note in section 4.2.7:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090622#sec-receipt-of-link-to-handheld
[[
Note that an empty href attribute indicates a "same document reference",
whereas the URI from which the document was retrieved does not. Need
confirmation or otherwise of this under Francois's ACTION-983
]]
This is not true. Same reference documents should not be retrieved either.
I would remove the note and amend the section to say:
[[
If the response is an HTML response and it contains a <link
rel="alternate" media="handheld" /> element, a proxy should request and
process the referenced resource, unless the reference is a "Same
Reference Document" as defined in RFC3986 section 4.4 [REF], e.g. an
empty href attribute or the URI of the HTML response.
]]
Francois.
Francois Daoust wrote:
> 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 Monday, 22 June 2009 16:03:37 UTC