- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Tue, 23 Oct 2007 18:11:40 +0100
- To: <public-bpwg-ct@w3.org>
I thought it worth making a note and stimulating further discussion following today's productive CT TF call. I'm worried that if we step into the space of how to do 3 way content negotiation we will be opening the lid on Pandora's box. The starting point, I think, is that there are three types of component, server, proxy and browser. Each of those can be capable of transformation. Add to this that each of them will independently also be aware or unaware of whatever our guidelines state about how to cooperate. So in theory at least there are 64 different combinations of aware/capable component types in the delivery chain. That's a bit too complicated for my taste. So I wonder if it's worth considering the question of repurposing the presentation separately from markup and formatting fixups? So far as presentation is concerned I think there's a relatively small set of cases, though each of them undoubtedly has its own complexity. Case 1. a) the Server has only a desktop oriented presentation only b) the browser has mobile presentation only A proxy may have a useful role in re-presenting the content. Note though, that in this case, the server's desktop presentation may actually be a universal presentation (call my web pages boring but they are designed to render across all delivery contexts) so in that case the proxy should not interfere either. Case 2. a) The Server has both a mobile and a desktop experience b) Client has mobile experience only Server presents mobile experience. Proxy stays out of the way. Case 3. a) The Server has a desktop oriented presentation only b) Client can simulate desktop Client goes ahead and simulates desktop (There is an argument that says that this could land the user in a delay and cost nightmare. So is that an argument against the concept of simulating desktop on a mobile, or is it an argument for saying that there is a role for transforming proxy to reduce that delay and cost nightmare?) Also same case as in 1, where the server has a single presentation, but that presentation is suitable across the board. Case 4. a) The server has a choice of presentations b) The client has a choice of presentations The user should be able to get either i) the mobile presentation ii) the simulated desktop presentation. That choice may be triggered by selection locally to the client or at the server. Case 5. Although this looks like a Web request, in fact it isn't. It's some ad hoc protocol xmlhttprequest-like thingy. (Proxy leaves well alone) I'm assuming that this is a more of less complete list of scenarios where the presentation is adjusted at most once. Now I think that we can consider on top of this whether the proxy has a role adjusting not the presentation, but details of the formatting - e.g. to tweak the content type header, or to tweak the DOCTYPE to avoid problems. Possibly to re-render images from one format to another. To my mind, that is almost certainly enough to do deal with in volume 1 of the guidelines. I think we should leave the door open to later elaborations that discuss 3 way content negotiation, servers deliberately delegating formatting or presentation tasks to proxies and so on. However all that falls firmly in a volume 2. I'm hoping that by restricting the initial scope we stand a chance of meeting the proposed timescales for the deliverable, and of addressing in a timely way the key point of the Task Force's existence - which is to provide a way for Transforming Proxies to get out of the way of mobile ready content. Hope this makes sense and looking forward to comments. Jo
Received on Tuesday, 23 October 2007 17:11:58 UTC