RE: ISSUE-222 (TAG Finding): TAG Finding on Alternative Representations [Content Transformation Guidelines]

Here are a couple of points that concerned me on reading the TAG
finding:

A. Under 2.1.1 I think that it is often hard or impossible to create
distinct URIs for all the representations. For example, many transcoding
proxies claim to work around specific known bugs in various devices
(famous example being to suppress id attribute in h2 for a particular
model of a particular phone because it crashes if that id is present.)

B. In 3 of the same section, use of the VARY header is promoted. This is
a very good idea, imo, but is use should be construed more widely than
to enable correct operation of caching proxies. We (dotMobi) published a
recommendation that sites that Vary make this known on all responses,
cacheable or not.

C. I'm dubious about 5 in that section - though I think this can provide
useful additional evidence, which transcoding proxies and user agents
can use to help with whatever additional heuristics they may choose to
implement. At its heart this mechanism is not applicable to formats that
don't support such linking mechanisms (e.g. I'm not sure where SVG
supports it or not), not to mention that the mechanisms in HTML are not
fine grained enough for this purpose - e.g. rel="alternate" (should be
alternative) media="handheld" will need to be repeated for each
"handheld" representation, and can't be used to represent that fact that
for example the representation varies by operator network. The situation
would be much improved, vis a vis link, if it were available as an HTTP
header (removed in HTTP 1.1 evidently).

D. Redirection - given that we are basically averse to redirection back
to the mobile device, the cost of redirection is mitigated when it is
fielded by a (transcoding) proxy. As I have mentioned I think it may be
time to open the lid on the 300 HTTP Response and provide a systematic
way to use it. Possibly in conjunction with Link. 

In general, though, I think it is true to say that many, if not most,
mobile sites don't have static versions of resources, they are almost
always dynamically generated, so redirects can usually be avoided, if it
is known what representation to serve. This may not be quite as
prevalent for e.g. images ...

E. The fact that there is no a priori way of distinguishing between URIs
that refer to a distinct representation of a resource and those that
don't is actually a nuisance, though hard to see what one would do about
it even if one wanted to. 

There may be a useful distinction between using a VARY header, which
indicates that the URI accessed identifies a resource (a canonical URI)
and a response that does not contain VARY - i.e. it's a static
representation of a resource, that can be LINKed to other static
representations and the Canonical URI. It's not clear to me that this is
what the paper is actually suggesting.

> -----Original Message-----
> From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Jo Rabin
> Sent: 03 October 2007 14:26
> To: public-bpwg-ct@w3.org
> Subject: FW: ISSUE-222 (TAG Finding): TAG Finding on Alternative
> Representations [Content Transformation Guidelines]
> 
> 
> Forwarding to CT for discussion:
> 
> -----Original Message-----
> From: member-bpwg-request@w3.org [mailto:member-bpwg-request@w3.org]
On
> Behalf Of Mobile Web Best Practices Working Group Issue Tracker
> Sent: 03 October 2007 14:24
> To: member-bpwg@w3.org
> Subject: ISSUE-222 (TAG Finding): TAG Finding on Alternative
> Representations [Content Transformation Guidelines]
> 
> 
> 
> ISSUE-222 (TAG Finding): TAG Finding on Alternative Representations
> [Content Transformation Guidelines]
> 
> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/
> 
> Raised by: Jo Rabin
> On product: Content Transformation Guidelines
> 
> Henry Thompson pointed me at the MUST READ document [1] which is a TAG
> finding that relates to our work on Content Transformation. I have
some
> comments on it and think it would be useful to discuss on the CT List.
> 
> Jo
> 
> [1] http://www.w3.org/2001/tag/doc/alternatives-discovery.html
> 
> 
> 
>

Received on Thursday, 11 October 2007 16:29:52 UTC