- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Thu, 22 May 2008 21:51:29 +0100
- To: Francois Daoust <fd@w3.org>
- CC: public-bpwg-ct <public-bpwg-ct@w3.org>
OK. Then this now assumes the status of a recommendation that content that is mobile SHOULD contain such a link? (Though if I were to be picky I'd wonder how a resource can be an alternative for itself ... ) Jo On 21/05/2008 16:33, Francois Daoust wrote: > > Replying to myself after further investigations... > > Dom reminded me that instead of "rev", which is probably correct but not > really ever used in practice, it is actually quite simple and > semantically valid to do the "linking to self" stuff with a <link> > element. The [uri] to set is simply... an empty string! > > Leading to: > <link rel="alternate" media="handheld" type="[content-type]" href="" /> > > Indeed, the href attribute may be an absolute or a relative link, and > thus the empty string here means "current page", which is exactly what > we need for B) below. > > Francois. > > > Francois Daoust wrote: >> >> Hi Aaron, >> Hi all! >> >> [Aaron, I'm pinging you more specifically on this because it seems >> that Google's transcoding proxy uses this mechanism, so you might be >> able to help with concrete practice here] >> >> We talked a bit about using the "link" element in HTML responses in a >> previous call [1] and a bit on the mailing-list [2] to advertise the >> fact that: >> A) a page _has_ a mobile representation that may be requested >> B) a page _is_ a mobile representation of a resource >> >> The linking mechanism seems simple in theory: >> <link rel="alternate" media="handheld" type="[content-type]" >> href="[uri]" /> >> as defined in the HTML4.01 spec [3] >> >> In practice, this addresses A, but not B, IMHO, at least not directly. >> The definition of rel="alternate" [4] makes it clear that [uri] points >> to an alternative representation of the _document_, from which I >> understand that "linking to self" should not be permitted, at least >> not in theory. Am I wrong? >> If I am, then [uri] can be the document itself, but then the questions >> Jo mentioned in [2] need to be answered to determine what constitutes >> a link to self: >> - when the server uses redirection, does [uri] target the originally >> requested URI, the final one, any of them? >> - what about query strings? It has to be part of [uri] if one is using >> "?experience=handheld", but aren't resources usually identified >> without the query string? >> >> >> It occurs to me that we haven't discussed the "reverse linking" >> mechanism, that may help address B. If you have a main page >> "index.html" that contains a link such as: >> <link rel="section" href="section1.html"> >> then "section1.html" may identify itself as a section of "index.html" >> by defining: >> <link rev="section" href="index.html" /> >> >> Given "desktop.html" and "handheld.html", can we define: >> <link rel="alternate" media="handheld" type="application/xhtml+xml" >> href="handheld.html" /> >> in "desktop.html" and: >> <link rev="alternate" media="handheld" type="application/xhtml+xml" >> href="desktop.html" /> >> in "handheld.html" to state that "handheld.html" is the "handheld" >> representation of "desktop.html"? >> >> I'd say yes, but I'm not quite sure this is a valid use of the "rev" >> mechanism. >> (and I don't quite think that anyone really uses the "rev" mechanism >> at all actually, but that should not be such a problem). >> >> Going back to the guidelines, I'd say: >> A) if a _forward_ (rel) link with a "handheld" media attribute is >> encountered, the proxy should redirect the user to the alternate >> representation >> B) if a _reverse_ (rev) link with a "handheld" media attribute is >> encountered, then that's it, we've found the handheld version! >> >> >> [1] http://www.w3.org/2008/05/06-bpwg-minutes.html#item03 >> [2] http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0011.html >> [3] >> http://www.w3.org/TR/1999/REC-html401-19991224/struct/links.html#h-12.3 >> [4] http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links >> >> >
Received on Thursday, 22 May 2008 20:52:50 UTC