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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

-- ends

Received on Wednesday, 30 July 2008 17:17:42 UTC