genericResources-53 On Linking Alternative Representations To Enable Discovery And Publishing

Tag Reference: genericResources-53
BPWG Reference: ISSUE-222

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] which is now in Last Call.

As mentioned in Dom's request of 1st August to TAG chairs for review of 
our Last Call Working Draft we would very much appreciate TAG comments 
on the attached comments.

Many thanks
Jo Rabin
BPWG co-Chair


a. Representation Specific URIs

[1] 2.1.1 Clause 1 "Create representation-specific URIs (specific
resources) for each available alternative (representation_i), e.g.,"

[1] 3 Bullet 3 "...For each such available representation that is
generated as a function of user context, ensure that there is a URI that
can reproduce that representation (specific resource) in the absence of
user context; or equivalently: for every representation, ensure that
there is a URI that hard-wires all user context e.g., language, device
preference etc., required to generate that specific resource."

As discussed in [1] 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". However, it is common for authors to form
categories or "device classes" like "smart phone" "feature phone" and
"basic phone" each with distinct representations. Variation can also 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.

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 - because the number of variations is not
known a priori, changes over time and the representation is determined
at the time of its retrieval.

b. Use of Redirection and 302 redirect

[1] 2.1.1 Clause 4 "As an alternative to the previous step, arrange for
the server to generate an HTTP 302 (Found) redirect to automatically
serve up when is accessed by user-agent_i. This form of
redirect involves an extra client/server round-trip, and may therefore
be suboptimal for mobile devices. This is a temporary redirect; the
accessing user-agent should continue to use the canonical URI when
creating bookmarks, or emailing URI."

In line with the above 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 (mobileOK Basic Tests 
[3]). 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.

Because of the value of having inter-operable bookmarks we encourage the
use of canonical URIs. However it is preferable for a mobile user to
bookmark a specific representation so that they do not needlessly get
redirected each time they visit the bookmark. As a consequence a 302
redirect may not be the best way of switching from the canonical URI to
the device class specific URI.


c. Using specific URIs to denote the context

[1] 3 Bullet 3 "Encourage users and user-agents to work with canonical
URIs; leave it to the underlying infrastructure to generate appropriate
redirects in order to serve users the appropriate representation
(specific resource)."

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.g. and (or /
etc. there are numerous variations).

d. 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. [1] 2.1.1 bullet 5) present in each representation variant.

[1] 2.1.1 Clause 3 "Ensure that the VARY headers capture the right
parameters that were used to choose the representation that is being
served  this is important for correct behavior when using cacheing

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.

Additionally we recommend use of the Vary header even when the response
is not cacheable to assist with determination of the authors intentions
in respect of a particular representation.

e. Link Element

[1] 4. bullet 3 "Hyperlinks can be designed either for human consumption
(HTML a element), purely for machine consumption (HTML link element), or
both. To maintain a single Web, ensure that the hyperlink structure of
the Web is leveraged to create a graph structure whose transitive
closure includes all available representations of a given generic resource."

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"

As noted above, 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 other content types where this feature
is not present. 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.

Note that the current proposal [4] for the link element does not propose 
an equivalent for the media attribute so as it stands might not be 
usable in an exactly analogous way.


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="" />
<link rel="alternate" media="screen" type="application/xhtml+xml"

This identifies how to retrieve appropriate representations, but does
not indicate which presentation media this representation is intended
for (assuming it was retrieved from

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 in a special way. There appears
to be no established convention for this, and we need to establish one.

So for example:

<link rel="alternate" media="handheld" type="application/xhtml+xml"
href="" />
<link rel="alternate" media="screen" type="application/xhtml+xml"

identifies that this representation is intended for handheld and that
the link should not be followed if a handheld representation is required.

[Note that the current document describes a different means of 
indicating this but it's likely that we will use the above cf RFC 3986 
section 4.4 [5] ]

-- ends

Received on Thursday, 7 August 2008 17:06:08 UTC