--- /tmp/old 2004-12-10 14:22:16.000000000 -0600 +++ /tmp/new 2004-12-10 14:21:50.000000000 -0600 @@ -1,18 +1,21 @@ W3C -Architecture of the World Wide Web, First Edition +Architecture of the World Wide Web, Volume One -W3C Proposed Recommendation 5 November 2004 +Editor's Draft 9 December 2004 This version: - http://www.w3.org/TR/2004/PR-webarch-20041105/ + http://www.w3.org/2001/tag/2004/webarch-20041209/ - Latest version: - http://www.w3.org/TR/webarch/ + Latest editor's draft: + http://www.w3.org/2001/tag/webarch/ Previous version: - http://www.w3.org/TR/2004/WD-webarch-20040816/ + http://www.w3.org/2001/tag/2004/webarch-20041203/ + + Latest TR version: + http://www.w3.org/TR/webarch/ Editors: Ian Jacobs, W3C @@ -54,33 +57,18 @@ replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than "work in progress." - This is the 5 November 2004 Proposed Recommendation of "Architecture - of the World Wide Web, First Edition." Publication as a Proposed - Recommendation indicates that W3C seeks endorsement of the stable - technical report. The W3C Membership and other interested parties are - invited to review the document and send comments to - public-webarch-comments@w3.org (with public archive) through 3 - December 2004. Advisory Committee Representatives should consult their - WBS questionnaires. Note that substantive technical comments were - expected during the Last Call review period that ended 17 September - 2004. A complete list of changes since the Last Call draft (and - earlier drafts) is available. + This is not the 5 November 2004 Proposed Recommendation of + "Architecture of the World Wide Web, Volume One." This document + incorporates some changes based on review of the 5 November 2004 + Proposed Recommendation. A complete list of changes since the Last + Call draft (and earlier drafts) is available. This document has been developed by W3C's Technical Architecture Group (TAG), which, by charter maintains a list of architectural issues. The scope of this document is a useful subset of those issues; it is not intended to address all of them. The TAG intends to address the - remaining (and future) issues after publication of the First Edition - as a Recommendation. As noted in the TAG's Proposed Recommendation - transition request, a few points of outstanding dissent regarding this - document remain: - 1. Stickler on "information resource" in the URI/Resource - Relationships (§2.2) section - 2. Kopecky on Representation of a secondary resource in the Fragment - Identifiers (§2.6) section - 3. HTML WG on XLink in the Links in XML (§4.5.2) section. In this - revision, that section has been changed to accommodate the HTML - WG's request, at least in part. + remaining (and future) issues after publication of Volume One as a + Recommendation. This document uses concepts and terms regarding URIs as defined by the IETF. In an 18 Oct 2004 announcement, the revision of RFC2396 was @@ -479,13 +467,15 @@ etc. as "resources". The distinguishing characteristic of these resources is that all of their essential characteristics can be conveyed in a message. We identify this set as "information - resources". + resources." This document is an example of an information resource. It consists of words and punctuation symbols and graphics and other artifacts that can be encoded, with varying degrees of fidelity, into a sequence of bits. There is nothing about the essential information content of this - document that cannot in principle be transfered in a representation. + document that cannot in principle be transfered in a message. In the + case of this document, the message payload is the representation of + this document. However, our use of the term resource is intentionally more broad. Other things, such as cars and dogs (and, if you've printed this @@ -741,22 +731,24 @@ Dirk would like to add a link from his Web site to the Oaxaca weather site. He uses the URI http://weather.example.com/oaxaca and labels his - link "weather in Oaxaca on 1 August 2004". Nadia points out to Dirk - that he is setting misleading expectations for the URI he has used. - The Oaxaca weather site policy is that the URI in question identifies - the current weather in Oaxaca--on any given day--and not the weather - on 1 August. Of course, on the first of August in 2004, Dirk's link - will be correct, but the rest of the time he will be misleading - visitors to his Web site. Nadia points out to Dirk that the weather - site does make available a different URI permanently assigned to a - resource describing the weather on 1 August 2004. - - In this story, there are two resources: "the current weather in - Oaxaca" and "the weather in Oaxaca on 1 August 2004". The Oaxaca - weather site assigns two URIs to these two different resources. On - 1 August 2004, the representations for these resources are identical. - That fact that dereferencing two different URIs produces identical - representations does not imply that the two URIs are aliases. + link "report on weather in Oaxaca on 1 August 2004". Nadia points out + to Dirk that he is setting misleading expectations for the URI he has + used. The Oaxaca weather site policy is that the URI in question + identifies a report on the current weather in Oaxaca--on any given + day--and not the weather on 1 August. Of course, on the first of + August in 2004, Dirk's link will be correct, but the rest of the time + he will be misleading readers. Nadia points out to Dirk that the + managers of the Oaxaca weather site do make available a different URI + permanently assigned to a resource reporting on the weather on 1 + August 2004. + + In this story, there are two resources: "a report on the current + weather in Oaxaca" and "a report on the weather in Oaxaca on + 1 August 2004". The managers of the Oaxaca weather site assign two + URIs to these two different resources. On 1 August 2004, the + representations for these resources are identical. That fact that + dereferencing two different URIs produces identical representations + does not imply that the two URIs are aliases. 2.4. URI Schemes @@ -1094,18 +1086,18 @@ expressive power of the representation's format will affect how precisely the representation provider communicates resource state. If the representation communicates the state of the resource - inaccurately, this inaccuracy or ambiguity may lead to confusion about - what the resource is. If different users reach different conclusions - about what the resource is, this may lead to URI collision (§2.2.1). - Some communities, such as the ones developing the Semantic Web, seek - to provide a framework for accurately communicating the semantics of a - resource in a machine readable way. Machine readable semantics may - alleviate some of the ambiguity associated with natural language - descriptions of resources. + inaccurately, this inaccuracy or ambiguity may lead to confusion among + users about what the resource is. If different users reach different + conclusions about what the resource is, they may interpret this as a + URI collision (§2.2.1). Some communities, such as the ones developing + the Semantic Web, seek to provide a framework for accurately + communicating the semantics of a resource in a machine readable way. + Machine readable semantics may alleviate some of the ambiguity + associated with natural language descriptions of resources. 3.2. Representation Types and Internet Media Types - A Representation is data that encodes information about resource + A representation is data that encodes information about resource state. Representations do not necessarily describe the resource, or portray a likeness of the resource, or represent the resource in other senses of the word "represent". @@ -1871,21 +1863,36 @@ 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). 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 design decision about where on this spectrum an application should - be placed depends on the power on the client, the power and the load - on the server, and the bandwidth of the medium that connects them. If - the number of possible clients is unbounded, the application will - scale better if more computation is pushed to the client. + the other. + + There are advantages to each approach. For instance when a client + (such as a mobile phone) communicates device capabilities to the + server (for example, using CC/PP), the server can tailor the delivered + content to fit that client. The server can, for example, enable faster + downloads by adjusting links to refer to lower resolution images, + smaller video or no video at all. Similarly, if the content has been + authored with multiple branches, the server can remove unused branches + before delivery. In addition, by tailoring the content to match the + characteristics of a target client, the server can help reduce client + side computation. However, specializing content in this manner reduces + caching efficiency. + + On the other hand, designing content that that can be recombined on + the client also tends to make that content applicable to a wider range + of devices. This design also improves caching efficiency and offers + users more presentation options. Media-dependent style sheets can be + used to tailor the content on the client side to particular groups of + target devices. For textual content with a regular and repeating + structure, the combined size of the text content plus the style sheet + is typically less than that of fully recombined content; the savings + improve further if the style sheet is reused by other pages. + + In practice a combination of both approaches is often used. The design + decision about where on this spectrum an application should be placed + depends on the power on the client, the power and the load on the + server, and the bandwidth of the medium that connects them. If the + number of possible clients is unbounded, the application will scale + better if more computation is pushed to the client. Of course, it may not be desirable to reach the widest possible audience. Designers should consider appropriate technologies, such as @@ -1995,8 +2002,7 @@ well suited to expression in XML. Design constraints that would suggest the use of XML include: 1. Requirement for a hierarchical structure. - 2. Immediate need for a wide range of tools on a variety of - platforms. + 2. Need for a wide range of tools on a variety of platforms. 3. Need for data that can outlive the applications that currently process it. 4. Ability to support internationalization in a self-describing way @@ -2241,7 +2247,7 @@ recognize schema-assigned IDs. See the TAG issue xmlIDSemantics-32 for additional background - information and [xml:id] for a solution under development. + information and [XML-ID] for a solution under development. 4.5.7. Media types for XML @@ -2305,8 +2311,7 @@ the information space infrastructure. The Semantic Web is one such application, built on top of RDF [RDFXML]. This document does not discuss the Semantic Web in detail; the TAG expects that future - editions of this document will. See the related TAG issue - httpRange-14. + volumes of this document will. See the related TAG issue httpRange-14. 5. General Architecture Principles @@ -2539,7 +2544,9 @@ A unit of communication between agents. Namespace document - The information resource identified by an XML Namespace URI + An information resource that contains useful information, + machine-processable and/or human-readable, about terms in a + particular XML namespace. Representation Data that encodes information about resource state. @@ -2744,7 +2751,7 @@ Available at: http://www.ietf.org/rfc/rfc2397.txt. RFC2616 - IETF RFC 2616: Hypertext Transfer Protocol — HTTP/1.1, J. + IETF RFC 2616: Hypertext Transfer Protocol - HTTP/1.1, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt. @@ -2836,6 +2843,12 @@ http://www.w3.org/TR/2001/REC-xlink-20010627/. Latest version available at http://www.w3.org/TR/xlink/. + XML-ID + xml:id Version 1.0, D. Veillard, J. Marsh, Editors, W3C Working + Draft (work in progress), 07 April 2004, + http://www.w3.org/TR/2004/WD-xml-id-20040407. Latest version + available at http://www.w3.org/TR/xml-id/. + XML10 Extensible Markup Language (XML) 1.0 (Third Edition), F. Yergeau, J. Paoli, C. M. Sperberg-McQueen, et. al., Editors, @@ -2874,12 +2887,6 @@ http://www.w3.org/TR/1999/REC-xslt-19991116. Latest version available at http://www.w3.org/TR/xslt. - xml-id - xml:id Version 1.0, D. Veillard, J. Marsh, Editors, W3C Working - Draft (work in progress), 07 April 2004, - http://www.w3.org/TR/2004/WD-xml-id-20040407. Latest version - available at http://www.w3.org/TR/xml-id/. - 7.1. Architectural Specifications ATAG10 @@ -2974,10 +2981,11 @@ list, www-tag@w3.org (archive), which have helped to improve this document. - In addition, contributions by David Booth, Kendall Clark, Karl Dubost, - Bob DuCharme, Martin Duerst, Olivier Fehr, Al Gilman, Tim Goodwin, - Elliotte Rusty Harold, Tony Hammond, Sandro Hawke, Dominique - Hazaël-Massieux, Masayasu Ishikawa, David M. Karr, Graham Klyne, Ken - Laskey, Jacek Kopecky, Susan Lesch, Frank Manola, Mark Nottingham, - Bijan Parsia, Peter F. Patel-Schneider, David Pawson, Michael - Sperberg-McQueen, and Patrick Stickler are gratefully acknowledged. + In addition, contributions by David Booth, Erik Bruchez, Kendall + Clark, Karl Dubost, Bob DuCharme, Martin Duerst, Olivier Fehr, Al + Gilman, Tim Goodwin, Elliotte Rusty Harold, Tony Hammond, Sandro + Hawke, Ryan Hayes, Dominique Hazaël-Massieux, Masayasu Ishikawa, David + M. Karr, Graham Klyne, Jacek Kopecky, Ken Laskey, Susan Lesch, Håkon + Wium Lie, Frank Manola, Mark Nottingham, Bijan Parsia, Peter F. + Patel-Schneider, David Pawson, Michael Sperberg-McQueen, Patrick + Stickler, and Yuxiao Zhao are gratefully acknowledged.