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

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

From: Jo Rabin <jrabin@mtld.mobi>
Date: Wed, 06 Aug 2008 16:12:02 +0100
Message-ID: <4899BF42.10502@mtld.mobi>
To: MWI BPWG Public <public-bpwg@w3.org>

Here is an updated draft proposed text in response to ACTION-703, ISSUE-222

Updated in response to comments from Dom and Francois, will be sent 
tomorrow if there are no objections.

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/2008/WD-ct-guidelines-20080801/


Discussion

a. Representation Specific URIs

[1] 2.1.1 Clause 1 "Create representation-specific URIs (specific 
resources) for each available alternative (representation_i), e.g., 
http://example.com/ubiquity/resource/representation_i."

[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 http://example.com/ubiquity/representation_i when 
http://example.com/ubiquity 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 [2]. 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.
example.mobi and example.com (or m.example.com / wwww.example.com
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 
proxies."

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.

f. 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.

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

[Note that the current document describes a different signifier. 
Information that has come to light since last call suggests that it's 
likely that it will be changed to the above in the next draft]

-- ends
Received on Wednesday, 6 August 2008 15:13:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:57 UTC