Re: PR-webarch-20041105

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