- From: Chris Lilley <chris@w3.org>
- Date: Mon, 29 Nov 2004 14:02:54 +0100
- To: public-webarch-comments@w3.org, howcome@opera.com
- Cc: www-tag@w3.org
Hi Håkon Thanks for your comments on the WebArch document. You bring up good points, which we intent to address at todays TAG f2f. It is unfortunate that the available space to cover this important and complex topic is fairly limited, especially in the first release of WebArch. As your mail points out, an over abbreviated wording can readily be misconstrued. The argument that well structured HTML pages, especially those with a regular and repeating style, are smaller when served as CSS plus HTML rather than a fully attributed form, is undisputed - you will recall that you and I contributed to a paper to that effect in 1997[1]. There is also an argument of caching efficiency, which is worsened when content tailored for particular devices is used. The comment about reduced size resulting from server-based processing was not, however, referring to this aspect at all. Instead, it was referring to the work of the DI working group, whose CC/PP framework for server side content adaptation allows, among other things, images and video to be tailored for the device. If the original content references an image that is 800 pixels wide, and the phone screen is 200 pixels wide, then sending the original image rather than a downsampled one merely makes the download 16 times larger for no benefit. I understand that Opera has a server based product that does these sorts of transformations.[2] Similarly, sending a movie clip only to find that the client does not have the required codec is wasteful. DI WG has also been looking at conditional authoring, which is one way to author content for a range of different devices, and serve it up in different ways (for example, a larger number of smaller pages) for different devices. This was the context in which the 'smaller amounts of data' statement was made. To resolve this ambiguity and more clearly describe the tradeoffs for the two extremes of the spectrum, the following revised text is suggested. Please let us know what you think of it. it will be discussed in the next couple of days at the TAG f2f. Note that when content, presentation, and interaction are separated by design, agents need to recombine them. There is a recombination spectrum, with "client does all" at one end and "server does all" at the other. There are advantages to each: sending device capabilities to the server (for example, using CC/PP) allows tailoring of the content to specific devices (such as mobile phones). For example links can be adjusted to point to lower resolution images, smaller video or no video at all, giving a faster download; if the content has been authored with multiple branches, the server can remove unused branches too. In addition a small amount of client side computation is saved. However, this makes the content more specific to a particular device, reducing caching efficiency. On the other hand, recombination on the client makes the delivered content applicable to a wider range of devices, improving caching efficiency. It can be tailored to particular groups of devices by using media specific style sheets. For textual content with a regular and repeating structure, the combined size of the text content plus the stylesheet is typically less than that of a fully recombined content; the savings improve further if the stylesheet is reused by other pages. In practice a combination of both approaches is often used, tailored to the particular content. [1] Network Performance Effects of HTTP/1.1, CSS1, and PNG NOTE 24-June 1997 http://www.w3.org/Protocols/HTTP/Performance/Pipeline [2] Formula 1 Mobile Browsing http://www.opera.com/products/mobile/accelerator/ -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group
Received on Monday, 29 November 2004 13:02:55 UTC