- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Tue, 05 Aug 2008 18:22:03 +0100
- To: Francois Daoust <fd@w3.org>
- CC: MWI BPWG Public <public-bpwg@w3.org>
Thanks Francois. I agree with almost all your comments. You won't be surprised to hear that I found this hard to write (given how long it took :-( ) so the result is something that wasn't really a "whole thought". Specifically I think that the summary and the discussion are not sufficiently different in length and as you say don't match anyway so I'll take the summary out. To assist readability and clarity I plan to quote the TAG finding in some places. The point about the 302 redirect is that I think we'd like it to be a 301 when serving to mobile - i.e. if bookmarked the redirected address is kept so you don't have to go through the redirection each time. More in line, thanks again (Incidentally folks, if you plan to comment pls do as tomorrow I will publish a final draft which I will send on Thursday, barring objections). Jo On 05/08/2008 10:23, Francois Daoust wrote: > 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. Agreed as above it's a mess. > > - 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 ;)). Hmm, think you are a bit obsessional about that Francois :-) > > >> >> 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. Well, it's impossible if you can't enumerate them and if you use DeviceAtlas to size pictures, for example, you can't reasonably. I'll add that example if it clarifies > > >> 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". No, as I mention above - I will clarify to say that this is basically the worst of both worlds. > > >> 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"? > as above > >> 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." I wasn't clear that that was what it meant. > > >> 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 > Well, I thought we had that discussion at the F2F and I thought Dom had a brilliant reason for discarding it. I remember successively trying 3 different ideas till one got the Dominesque nod. And I thought one of them was specifically this. I will check the minutes out and see if my memory is at fault and find the reason that an empty reference did not meet with approval. > "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 ;) > Yeah!
Received on Tuesday, 5 August 2008 17:23:16 UTC