FW: Content Transformation Action Items

Reposting as ACTION-551 for trackbot

-----Original Message-----
From: Aaron Kemp [mailto:kemp@google.com] 
Sent: 22 September 2007 21:06
To: Jo Rabin
Cc: public-bpwg-ct@w3.org
Subject: Re: Content Transformation Action Items

> A gentle reminder, folks, that the action items on the Transformation
> Guidelines are now past due.

Apologies for not getting this done on time.

I have not had time to do anything with 2.2, but I have some content for
2.3.

A version is available online [1] but I have included the text in this
message as well.  Since this is the first time I have contributed to
such a document, I hope it is at least somewhat appropriate.

2.3 Guidance for Content Transformation Server Developers
Most mobile devices have a limited capacity for receiving and
displaying content that was originally designed for a desktop browsing
environment.  A content transformation server may be used to adapt
desktop content in such a way that it may be successfully retrieved
and rendered by a mobile device.  A few of the well known limitations
include:

    * Poor or non-existent support for markup other than well-formed
XHTML
    * Limited image format support (eg, JPEG only)
    * Limited memory capacity for document retrieval and processing
    * Poor or non-existent HTTPS support
    * Poor or non-existent CSS support

In many cases, sending a mobile content that it was not prepared to
process will cause serious failures, often forcing the user to reset
the device.  A content transformation server can ensure that the
content will be suitable for display on the device, allowing the user
to access the information they desire.

Even in cases where no actual content transformation is strictly
necessary, a content transformation server can improve the experience
greatly by reducing the amount of data that must be transferred to the
mobile.  Decreasing the number of connections required by in-lining
style sheets and other resources can also dramatically reduce the
amount of time spent retrieving and rendering page content.

Some websites provide a mobile alternative that is suitable for
display on some mobile devices.  Unfortunately, the vast majority of
websites do not, and those that do often cater only to a small subset
of the mobile devices that are in active use.  Furthermore, many sites
actively detect and divert non-desktop browsers to "incompatible
browser" pages and the like, preventing the user from seeing any
content at all.  In these situations, a content transformation server
that "pretends" to be a desktop browser on behalf of the mobile can
provide a better experience by retrieving and processing the original
desktop-oriented site.  In the event that a website author does
provide a viable mobile alternative, any content transformation
servers in the delivery chain should recognize this content as
acceptable for mobile display and not attempt to modify it.

In order to increase the chances that a website will provide a viable
mobile alternative, content transformation servers should preserve and
pass on any information about the delivery context that is available.
This includes but is not limited to preserving the HTTP User-Agent and
Accept headers.

[This is an issue I am not actually sure what we want to do about.  On
the one hand, we need to present valid device information to the
origin server so that it may provide a mobile experience, but we also
want to masquerade as a desktop browser to cover the (much more
common) case where the site will refuse to send content for unknown
user agents.  There are several possible strategies, but we will need
to come up one that we can all agree on to present here.]

[TODO: Details of how content transformation servers communicate with
the rest of the delivery chain]

----

[1] http://docs.google.com/View?docid=dgx7k6xj_22d62rh5

Received on Tuesday, 2 October 2007 14:19:45 UTC