Index: webarch.html =================================================================== RCS file: /w3ccvs/WWW/2001/tag/webarch/webarch.html,v retrieving revision 1.84 diff -u -r1.84 webarch.html --- webarch.html 17 Jul 2003 00:23:42 -0000 1.84 +++ webarch.html 22 Jul 2003 17:19:43 -0000 @@ -75,19 +75,19 @@

Abstract

-

The World Wide Web is a networked information system. Web -Architecture consists of the requirements, constraints, principles, -and choices that influence the design of the system and the behavior -of agents within the system. When Web Architecture is followed, the -large-scale effect is that of an efficient, scalable, shared -information space. The organization of this document reflects the -three divisions of Web architecture: identification, representation, -and interaction. This document also addresses some non-technical -(social) issues that play a role in building -the shared information space.

- -

This document strives to establish a reference set of requirements, -constraints, principles, and design choices for Web architecture.

+

The World Wide Web is an information system that relates +information sources and services through the use of hypertext-style +relationships, creating a web of information that spans the Internet. +Architecture defines the desired operational behavior of components +within the system, including software, machine, and human components, +and protocols for interactions between components. The Web architecture +is influenced by social requirements and software engineering principles, +leading to design choices that constrain the behavior of the Web in order +for the system to achieve desired properties: an efficient, scalable, +shared information space that will continue to grow indefinitely +across languages, cultures, and information mediums. This document +is organized to reflect the three dimensions of Web architecture: +identification, representation, and interaction.

@@ -100,7 +100,13 @@

This document has been developed by W3C's Technical Architecture Group -(TAG) (charter).

+(TAG) (charter). +Please send comments on this document to the public W3C TAG mailing list +www-tag@w3.org (archive). +A complete list of +changes since the previous Working Draft is available on the +Web.

This draft is an Editor's Draft and some new content has not yet been reviewed by the TAG. The primary changes in this draft were @@ -116,27 +122,21 @@ specific architecture issues. Parts of those findings may appear in subsequent drafts. Please also consult the list of issues under -consideration by the TAG.

- -

This draft includes some editorial notes and also references to open TAG issues. These do not represent all open issues in the document. They are expected to disappear from future drafts.

-

Publication as a Working Draft does not imply endorsement by the W3C -Membership. This is a draft document and may be updated, replaced or -obsoleted by other documents at any time. It is inappropriate to cite this -document as other than "work in progress."

-

The latest information regarding patent disclosures related to this document is available on the Web. As of this publication, there are no disclosures.

-

Please send comments on this document to the public W3C TAG mailing list -www-tag@w3.org (archive).

- -

A list of current W3C Recommendations and +

Publication as a Working Draft does not imply endorsement by the W3C +Membership. This is a draft document and may be updated, replaced or +obsoleted by other documents at any time. It is inappropriate to cite this +document as other than "work in progress." +A list of current W3C Recommendations and other technical documents can be found at the W3C Web site.

@@ -155,11 +155,18 @@

Introduction

-

The World Wide Web (or, Web) is a networked information system -consisting of agents (programs -acting on behalf of a person, entity, or process) that exchange -information. Here's a simple travel -scenario illustrating a common Web interaction:

+

The World Wide Web (WWW, or simply Web) is an information system +that relates information sources and services, referred to collectively +as resources, through +the use of hypertext-style relationships, creating a web of information +that spans the Internet. The Web's primary goal is to create and +maintain an efficient, scalable, shared information space that will +continue to grow indefinitely across languages, cultures, and +information mediums.

+ +

A simple travel scenario +is used throughout this document to illustrate typical behavior of Web +components and describe their interactions:

-

This scenario illustrate the three architectural divisions -of the Web that are discussed in this document:

+

The scenario illustrates three dimensions of Web architecture +that are discussed in this document:

    -
  1. Identification. Objects - in the networked information system called resources are identified - by Uniform Resource Identifiers - (URIs). The URI in the travel scenario is - http://weather.example.com/oaxaca. -
    2. -
  2. Representation. Agents (such - as servers, browsers and multimedia players) - communicate resource state through a non-exclusive set of data - formats, used separately or in combination (e.g., XHTML, CSS, PNG, XLink, - RDF/XML, SVG, SMIL animation). In the travel scenario, Dan's user - agent uses the URI to request a representation of the identified - resource. In this scenario, the representation consists of - XHTML with embedded weather maps in SVG. -
    3. -
  3. Interaction. Agents exchange representations - via a non-exclusive set of protocols, including HTTP, FTP, and SMTP@@Text here on why SMTP part of -Web@@. - In the travel scenario, Dan's browser uses HTTP to - download the representation.Although many URI schemes are named after - protocols, this does not imply that use of such a URI will result in - access to the resource via the named protocol. When a URI is used to - retrieve a representation of a resource, that access might be - through gateways, proxies, caches, and name resolution services that - are independent of the protocol associated with the scheme name, and - the resolution of some URIs may require the use of more than one - protocol (e.g., both DNS and HTTP are typically used to access an - "http" URI's origin server when a representation isn't found in a - local cache). Other protocols than HTTP may be used to interact - with a resource identified by an HTTP URI. +
  4. Identification. Each resource is + identified by a Uniform Resource Identifier (URI). + In the travel scenario, Dan enters a URI into his user agent (browser) + and commands it to perform a retrieval action for the identified resource. + The user agent uses its configuration to determine how to locate the + identified information, which may be via a cache of prior retrieval + actions, by contacting an intermediary, or by direct access to the + information authority defined by the URI. User agent configurations + are usually defined by URI scheme, with exceptions defined by further + substring matches within the URI.
    5. + +
  5. Representation. Components (e.g., + servers, proxies, browsers, spiders, multimedia players, etc.) + using the Web communicate via messages that exchange representations + of resource information, corresponding to the state of an identified + resource, the content of a data-entry form, or the status of an action. + A representation communicates information through a non-exclusive + set of data formats, used separately or in combination (e.g., XHTML, + CSS, PNG, XLink, RDF/XML, SVG, SMIL animation, etc.). In this scenario, + the representations consist of an XHTML document and several + SVG weather map images.
    6. + +
  6. Interaction. Components exchange + representations via a non-exclusive set of messaging protocols + (e.g., HTTP, FTP, NNTP, SMTP, etc.) in accordance with actions + requested by a user or called for by the rendering engine while + processing hypermedia-aware data formats. Protocols define the + syntax and semantics of component interactions, as well as the + sequence of interactions expected for a given task. In the travel + scenario, Dan's browser uses HTTP to retrieve a representation + from the origin server at "weather.example.com" and interprets the + rendering instructions found within the XHTML representation, which + in turn calls for retrieval of weather maps through reference of + their URIs, which results in rendering the SVG images. The final + rendered result of these interactions, referred to as a + Web page, is defined + by the application steady-state between the last interaction and + the next user request.
+

Architecture defines the desired operational behavior of components +within the system, including software, machine, and human components, +and protocols for interactions between components. The Web architecture +is influenced by social requirements and software engineering principles, +leading to design choices that constrain the behavior of the Web in order +for the system to achieve desired properties. This document is an ongoing +attempt to describe the properties we desire of the Web and +the design choices that have been made to achieve them.

+

Editor's note: Todo: Introduce notions of client and server. Relation of client to agent and user agent. Relation of server to resource owner.

@@ -227,7 +250,7 @@

The intended audience for this document includes:

    -
  1. Participants in W3C Activities, i.e., developers +
  2. Participants in W3C Activities; i.e., developers of Web technologies and specifications in W3C.
  3. Other groups and individuals developing technologies to be integrated into the Web.
    4. @@ -368,8 +391,8 @@ licensed to do (e.g., by specification, or community convention, or site-specific convention) take responsibility for any problems that result. For instance, agents should not assume that -http://weather.example.com/Oaxaca and -http://weather.example.com/oaxaca identify the same +"http://weather.example.com/Oaxaca" and +"http://weather.example.com/oaxaca" identify the same resource, since none of the specifications involved states that the path part of an HTTP URI is case-insensitive. Web servers may vary in how they are configured to handle case-sensitivity. Agents that assume @@ -390,8 +413,8 @@ it follows that URI producers should be conservative about the number of different URIs they produce for the same resource. For instance, the parties responsible for weather.example.com have no reason to use -both http://weather.example.com/Oaxaca and -http://weather.example.com/oaxaca to refer to the same +both "http://weather.example.com/Oaxaca" and +"http://weather.example.com/oaxaca" to refer to the same resource; agents will not detect the equivalence relationship. In this case, one URI should be chosen and used consistently. See section 6.3 of [URI] for further advice on how to reduce the @@ -400,7 +423,7 @@

    URI consumers cannot, in general, determine the meaning of a resource by inspection of a URI that identifies it. In our travel scenario, the example URI -(http://weather.example.com/oaxaca) suggests that the +"http://weather.example.com/oaxaca" suggests that the identified resource has something to do with the weather in Oaxaca. Although short, meaningful URIs benefit people, URI consumers must not rely on the URI string to communicate the meaning of a @@ -483,7 +506,7 @@ authority providing information about the weather in Oaxaca register a new URI scheme "weather" for the identification of resources related to the weather? They might then publish URIs such as -weather://travel.example.com/oaxaca. While the Web +"weather://travel.example.com/oaxaca". While the Web Architecture allows the definition of new schemes, there is a cost to registration and especially deployment of new schemes. When an agent dereferences such a URI, if what really happens is that HTTP GET is @@ -577,9 +600,9 @@

    In our travel scenario the server returns an XHTML representation when Dan dereferences the URI -http://weather.example.com/oaxaca. Then, by navigating +"http://weather.example.com/oaxaca". Then, by navigating within the XHTML content, Dan finds that the URI -http://weather.example.com/oaxaca#tom refers to +"http://weather.example.com/oaxaca#tom" refers to information about tomorrow's weather in Oaxaca. This URI includes the fragment identifier "tom" (the string after the "#").

    @@ -599,7 +622,7 @@

    For URI schemes that do specify the use of fragment identifiers, the syntax and semantics of those identifiers is defined by the set of -representations that might result from +representations that might result from a retrieval action on the primary resource. The presence of a fragment identifier component in a URI does not imply that a retrieval action will take place.

    @@ -619,13 +642,13 @@

    Suppose that the managers of weather.example.com provide a visual map of the meteorological conditions in Oaxaca as part of the representation served for -http://weather.example.com/oaxaca. They might encode the +"http://weather.example.com/oaxaca". They might encode the same visual map in a number of image formats to meet different needs (e.g., they might serve PNG, SVG, and JPEG/JFIF). Dan's user agent and the server engage in HTTP content negotiation, so that Dan receives the best image format his user agent can handle or the format he usually prefers. The URI -http://weather.example.com/oaxaca/map#zicatela refers to +"http://weather.example.com/oaxaca/map#zicatela" refers to a portion of the weather map that shows the Zicatela Beach, where Dan intends to go surfing. Clients can do something useful with the fragment identifier and the SVG representation, since SVG defines fragment @@ -698,7 +721,7 @@ a Representation

    One of the most important actions involving a resource is to retrieve a representation of it (for +href="#representation">representation of it (for example, by using HTTP GET). As stated above, the authority responsible for a URI determines what the URI identifies and which representations are used for @@ -987,7 +1010,7 @@

-

Representations

+

Representation

A representation is data that represents or describes @@ -1025,7 +1048,7 @@ requests at all;

  • Whether the agents responsible for weather.example.com make available one or more representations for the resource - identified by http://weather.example.com/oaxaca;
    • + identified by "http://weather.example.com/oaxaca";
  • Whether Dan has access privileges to such a representation;
  • If the agents responsible for weather.example.com have provided more than one representation (in different formats such as HTML, PNG, or RDF,