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

No objections Jo.

Please remember to cc Mark Nottingham when you send this (mnot@mnot.net).

Cheers

Phil.

Jo Rabin wrote:
> 
> 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
> 
> 
> 
> 
> 
> 

-- 
Phil Archer
Chief Technical Officer,
Family Online Safety Institute
w. http://www.fosi.org/people/philarcher/

Received on Wednesday, 6 August 2008 15:16:37 UTC