PR-webarch-20041105

Opera Software has the following technical comments to Architecture of
the World Wide Web, First Edition [1]:

First, we support the views expressed by the HTML WG wrt. Xlink. 

Second, we think section 4.3 (Separation of Content, Presentation, and
Interaction) should be slightly revised. The specification currently
says:

 | 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: recombination on the server
 | allows the server to send out generally smaller amounts of data that
 | can be tailored to specific devices (such as mobile phones).

We agree about the "spectrum" part and about the conclusion of the
section, but the argument that "recombination on the server allows the
server to send out generally smaller amonts of data" is not correct.
Generally, the opposite is true: recombination in the client results
in smaller amounts of data. Consider this example:

 <html>
   <style>
     P { font: bold 10px sans-serif }
   </style>
   <body>
     <p>foo
     <p>bar
     <p>foobar
   </body>
 </html>

The document above separates the presentation from the content and the
client will have to do some work to recombine them; the font
declaration must be copied into each <p> element.

If the server had combined the presentation and the content, the
resulting markup would have been more verbose since the property
values would have to be place on each element:

  <div font-weight=bold font-size=10px font-family=sans-serif>foo</div>
  <div font-weight=bold font-size=10px font-family=sans-serif>bar</div>
  <div font-weight=bold font-size=10px font-family=sans-serif>foobar</div>

(an imaginary presenational language is used above, the result would
have been the same if XSL-FO had been used)

Alternatively, the server bave converted the document to the ultimate
presentation: an image. Most likely, the result would have been even
bigger.

Another data point: documents represented in HTML are typically 1/10
the size of PDF documents. 

By separateing content from presentation, one level of indirection is
added. This indirection will -- much like a hash table -- save space. 

 | However, such data will not be readily reusable by other clients
 | and may not allow client-side agents to perform useful tasks
 | unanticipated by the author. When a client does the work of
 | recombination, content is likely to be more reusable by a broader
 | audience and more robust. However, such data may be of greater size
 | and may require more computation by the client.

The last sentence put forward two arguments against the separation of
content and presentation: size and computation. As discussed above,
the "size" argument is false, but the "computation" is correct.

We suggest the following rewrite of the paragraph after the "good
practice" box in section 4.3:

  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: recombination on the server
  allows the server to perform some of the work which the client
  otherwise would have to do. However, such data will not be readily
  reusable by other clients and may not allow client-side agents to
  perform useful tasks unanticipated by the author. When a client does
  the work of recombination, content is likely to be more reusable by
  a broader audience and more robust. Also, the amount of data
  transmitted by the server will generally be smaller. However, such
  data may require more computation by the client.

[1] http://www.w3.org/TR/2004/PR-webarch-20041105/

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Friday, 12 November 2004 15:05:06 UTC