W3C home > Mailing lists > Public > public-bpwg@w3.org > August 2008

Re: ACTION-703 ISSUE-222 Draft text: On Linking Alternative Representations To Enable Discovery And Publishing

From: Francois Daoust <fd@w3.org>
Date: Tue, 05 Aug 2008 11:23:07 +0200
Message-ID: <48981BFB.2010509@w3.org>
To: Jo Rabin <jrabin@mtld.mobi>
CC: MWI BPWG Public <public-bpwg@w3.org>

Hi Jo,

Thanks for the draft and thanks for giving me some time to review it.

I do have a couple of comments on the message as a whole:

- I'm fine with the short summary followed by a more detailed 
discussion, but I think both structures should match in that case. I 
expected 1.b to match 2.b, but that's not the case. I would suggest to 
shuffle part 1. a bit so that someone quickly going through the summary 
may check the details of a particular point easily. If that's not what 
you had in mind with the summary, then I would suggest to merge both 
sections.

- Some sections seem to say the same thing as the TAG Finding does, and 
candidly speaking I got a bit lost on the specific parts where we want 
to draw the attention of the TAG on guidelines that don't quite fit with 
our experience with the Content Transformation Guidelines. See below my 
comments on sections 2.b, 2.c, and 2.d.

And the rest is inline...

HTH,
Francois.


Jo Rabin wrote:
> 
> Here is a draft proposed text in response to ACTION-703, ISSUE-222:
> 
> I think it needs more work, but have run out of time today.
> 
> Jo
> 
> -- begins
> 
> Ref the TAG finding "On Linking Alternative Representations To Enable 
> Discovery And Publishing" [1] I have been asked to communicate the 
> experiences of the Mobile Web Best Practices Working Group (BPWG)  in 
> interpreting it in the context of its work, especially the Content 
> Transformation Guidelines [2].
> 
> We would very much appreciate TAG review of our Last Call Working Draft 
> of the Content Transformation Guidelines and comments on the attached 
> discussion.
> 
> Many thanks
> Jo Rabin
> BPWG co-Chair
> 
> [1] http://www.w3.org/2001/tag/doc/alternatives-discovery.html
> [2] http://www.w3.org/TR/ct-guidelines

For the sake of posterity, I'd link to the date-spaced URI:
  http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/
... well some folks around there may still type URIs in (I do, but I 
still type date-spaced URIs ;)).


> 
> 1. General Summary
> 
> a. In mobile it is very common for Web sites to vary the representation 
> of resources and it's often hard or impossible to create distinct URIs 
> for all possible representations.

I suggest to drop "or impossible", unless there is one example where it 
really is.


> b. That said, it is often convenient to use different URIs for different 
> classes of representation (e.g. desktop vs mobile) and then to further 
> vary the representation of resources.

OK. Per my first comment on structure, I would merge that with 1.a so 
that it specifically matches 2.a.

> 
> c. We are basically averse to redirection and recommend that it is 
> minimized or avoided when serving to mobile. We question the 
> recommendation to use 302 redirects.

As mentioned in part 2.b below, the TAG Finding, clause 4 of 2.1.1, says:
"As an alternative to the previous step, arrange for the server to 
generate an HTTP 302 [...]. This form of redirect involves an extra 
client/server round-trip, and may therefore be suboptimal for mobile 
devices."

I take that as a not-so-good possibility with clear drawbacks, and not 
as a recommendation. "We question the recommendation to use 302 
redirects" makes it sound like we missed that part. I think we're saying 
the very same thing, although we would replace "may be" in the quote 
above by "is".


> d. We have adopted the suggested use of link elements and the Vary HTTP 
> header as promoted by the TAG finding. We'd add that we think it is good 
> practice to use the Vary HTTP header even when the resource is not 
> cacheable. We also have detailed comments on how to use the link element 
> on representations that vary.

OK.

> e. We think that the link mechanism promoted for HTML should be 
> available for all types of content and we think the link header that 
> used to be in HTTP appears to be suitable for that purpose.

OK.


> f. We recommend that while content providers should attempt to present 
> an appropriate user experience based on context characteristics, it is 
> good practice also to provide the ability for users to choose an 
> alternative representation. In some circumstances it seems to be 
> important to indicate that such a choice has been made, in a machine 
> processable way, but there does not appear to be a mechanism for 
> achieving this.

OK.

> 
> 2. Discussion
> 
> a. Representation Specific URIs
> 
> As discussed in [1 Introduction] in the mobile world it is very common 
> for there to be multiple representations for different delivery 
> contexts. The variations between representations can be quite coarse 
> e.g. "desktop" vs "mobile" or can be at an extremely granular level with 
> variations of the representation on a per user agent or even per user 
> agent software version. Often both types of variation are present - e.g. 
> an example.mobi and example.com (or m.example.com / wwww.example.com 
> etc. there are numerous variations).
> 
> Where such variation is at even a moderately granular level it is 
> usually impractical to follow the suggestion in 2.1.1 clause 1 to create 
> representation specific URIs.

OK.


> 
> b. Use of Redirection
> 
> In line with clause 4 of 2.1.1 (of [1]) we recommend trying to reduce 
> the number of redirects because of the increased latency that 
> introduces. We encourage content providers to keep the number of 
> requests to render a resource to fewer than 10 []. Even for a simple 
> page, with a style sheet and 3 images, if all the resources are 
> retrieved via redirection the count of retrievals soon exceeds the 
> suggested limit.

Small typo: [] should be [2].

> 
> c. Use of 302 Redirect
> 
> Because of the value of having inter-operable bookmarks we encourage the 
> use of canonical URIs. However, given the above on redirection, it is 
> preferable for a mobile user to bookmark the specific representation 
> that would automatically be chosen for them the next time they visit the 
> URI rather than go through a process of redirection on every visit. As a 
> consequence a 302 redirect may not be the best way of switching from the 
> canonical URI to the device class specific URI.

OK for both points above. I just note it says the same thing as the TAG 
Finding, and as such, I am not sure of the point we're trying to make 
her. Or should I say "it says the same thing as my reading of the TAG 
Finding"?


> d. Using specific URIs to denote the context
> 
> It's also worth noting that having device class specific URIs may not be 
> just a matter of engineering convenience, but may also be part of a 
> deliberate effort to advertise the presence of different 
> representations, and to provide the user with choice, where such a 
> choice is appropriate to their context. For example, a user of an 
> advanced mobile device with both 3G and WiFi connectivity might choose a 
> deliberately mobile experience when out of reach of WiFi even though 
> their device is inherently capable of providing a satisfactory 
> experience of a desktop representation, for cost, speed and contextual 
> reasons.
> 
> In this case at least, we feel it is better to advertise the 
> contextually specific URIs as well as any canonical one.

OK. Again, I think it goes in the same direction as clause 5 of section 
2.1.1 illustrated by the figure in section 6:
"Additional dotted arcs indicate that the content provider may create 
additional links that connect specific resources."


> e. Machine Readable Indication of User Choice
> 
> Because of the difficulty and relatively low accuracy of determining 
> device classes, and the consequent likelihood of error - and because in 
> any case the user may wish to alter the automatic choice for contextual 
> reasons (or, in the context of transformation proxies, may choose a 
> transformed desktop representation over a native mobile representation) 
> - we recommend that content providers offer user the option to change 
> the representation by means of "links intended for human consumption" 
> (cf. 2.1.1 bullet 5) present in each representation variant.
> 
> If a user has made a choice of representation then the content provider 
> may (should) "remember" that choice, and may use cookies to persist that 
> choice. In such a situation the use of the Vary header might be 
> considered to be misleading, in that the representation that is being 
> served is not the automatic choice and caches need to be aware that this 
> is in effect "the wrong representation" for the headers indicated. So in 
> this case it would seem that use of the Vary header requires 
> additionally the use of Cache-Control: private. However we think that 
> especially where transformation proxies are involved this is not a 
> strong enough semantic and that there is justification for a clearer 
> machine readable indication that user choice of representation in in 
> effect.

Looks good!

> 
> f. Link Element
> 
> We have followed the TAG Finding in respect of recommending the use of 
> the link element but in doing so have observed a number of issues.
> 
> i. Granularity of "handheld"
> 
> It's common for content providers to create more than one mobile 
> experience (corresponding typically to some classification of the 
> capabilities into "low", "medium" and "high" function devices). 
> Consequently there is a difficulty in providing machine processable link 
> information, since each of the alternatives is correctly identifiable as 
> "handheld". It's not clear how one might expand the repertoire of such 
> classes in a useful way, so it's difficult to follow the advice of the 
> TAG finding on using the link element unless all handheld experiences 
> are served from the same URI.
> 
> ii. Need for Link HTTP Header
> 
> Given that the link element is an artefact of HTML, it's not possible to 
> follow this finding in respect of many other content types. We think it 
> would be highly desirable to do so, especially in respect of images, and 
> think that the (abandoned) Link HTTP Header would seem to offer an 
> opportunity to add the semantics associated with the link element to all 
> content types.
> 
> iii. Identification of a Particular Representation
> 
> When more than one user experience is served from the same URI there is 
> an ambiguity in using the link element to determine which representation 
> has been served.
> 
> For example consider the following fragment:
> 
> <link rel="alternate" media="handheld" type="application/xhtml+xml" 
> href="http://example.com" />
> <link rel="alternate" media="screen" type="application/xhtml+xml" 
> href="http://example.com"/>
> 
> This identifies how to retrieve appropriate representations, but does 
> not indicate which presentation media this representation is intended 
> for (assuming it was retrieved from example.com).
> 
> At various points in the transformation document we need to know this, 
> and we have adopted the convention that when more than one presentation 
> media type is served from the same URI, the intended presentation media 
> type of this representation is signified by adding a fragment identifier 
> identifying a document local reference. So for example:
> 
> <link rel="alternate" media="handheld" type="application/xhtml+xml" 
> href="http://example.com#top" />
> <link rel="alternate" media="screen" type="application/xhtml+xml" 
> href="http://example.com"/>
> 
> identifies that this representation is intended for handheld and that 
> the link should not be followed if a handheld representation is required.

The whole part f. looks good!

Well, on the particular mechanism described in f) iii), I'd say that 
Josť made a point yesterday on public-bpwg-comments:
http://lists.w3.org/Archives/Public/public-bpwg-comments/2008JulSep/0038.html

RFC 3986 makes it clear that same-document references are references to 
the current representation of a resource and not the resource itself:
http://www.rfc.net/rfc3986.html#s4.4

"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"

Unless someone finds some spec that states otherwise, we should probably 
mention that this recently came up to our ears, and ask if there is 
still room for another interpretation in the context of links to 
alternative representations. And blame Dom in case there really isn't, 
of course ;)
Received on Tuesday, 5 August 2008 09:22:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:52 UTC