Architecture of the World Wide Web

Editor's Draft 16 June 2003

This version:
Latest editor's draft:
Previous version:
Latest version:
Ian Jacobs, W3C
See acknowledgments.


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.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

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

The primary change in this draft is the development of section 2. A list of changes in this document is available.

This draft remains incomplete; sections 1, 2, and 3 are the most developed; 4 the least. The TAG has published a number of findings that address 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 other technical documents can be found at the W3C Web site.

Table of Contents

Highlighted entries in this table of contents link to principles, constraints, good practice notes, and design choices emphasized in the document.

1. 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. This document describes the three architectural divisions of this information system:

  1. Identification. Agents identify objects in the system, called "resources," with Uniform Resource Identifiers (URIs).
  2. Representation. Agents represent, describe, and communicate resource state with a nonexclusive set of data formats, used separately or in combination (e.g., XHTML, CSS, PNG, XLink, RDF/XML, SMIL animation).
  3. Interaction. Agents exchange representations via a non-exclusive set of protocols, including HTTP, FTP, and SMTP1

1.1. Scenario

The most comment user experience on the Web today is summarized by the following interaction loop:

  1. Starting with a URI, the user (via a user agent) requests a representation of the identified resource. The protocol chosen for the request determines the structure and capabilities of the request (and response).
  2. If the request is successful, the response provides the user agent with a representation, consisting of data and metadata (such as the Internet Media Type of the data). The data may include URIs so the process can be repeated.

Here's a more detailed scenario: Suppose Dan is planning a vacation to Mexico and wishes to learn about the weather in Oaxaca. In a glossy travel magazine, Dan finds a URI for a Web site that reports on the weather in Oaxaca. This resource is identified by the URI http://weather.example.com/oaxaca. This is an "HTTP URI" (see the section on URI schemes), so:

  1. The entity responsible for weather.example.com has the authority to make available representations of this resource; weather.example.com is the authority component of an HTTP URI, as defined in [URI]. The people managing weather.example.com set up a server to handle requests for representations of the resource in question.
  2. The HTTP protocol [RFC2616] is the protocol used to request a representation.

Dan's client sends a request to a server at weather.example.com, with the URI http://weather.example.com/oaxaca. The representation Dan receives (and whether he receives one at all) depends on a number of factors, including:

  1. Whether the people managing weather.example.com respond to requests at all;
  2. Whether the people managing weather.example.com make available one or more representations for the resource identified by http://weather.example.com/oaxaca;
  3. Whether Dan has access privileges to such a representation;
  4. If the people managing weather.example.com have provided more than one representation (in different formats such as HTML, PNG, or RDF, in different languages such as English and Spanish, etc.), the result representation may depend on negotiation between the client and server that occurs as part of the HTTP transaction.
  5. When Dan made the request. Since the weather in Oaxaca changes, Dan should expect that representations will change over time.

If all goes well, the representation sent back to Dan's client includes data (say, an HTML document) and metadata about that data (including the Internet Media Type text/html). Dan's client renders the resulting HTML, which includes URIs, and Dan can follow a link to start the process again.

Throughout this document, we elaborate on this scenario to introduce and illustrate architectural principles.

1.2. About this Document

The intended audience for this document includes:

  1. Participants in W3C Activities,
  2. Other groups and individuals developing technologies to be integrated into the Web.
  3. Implementers of W3C specifications, and those who use the resulting products.

The authors have made every effort to keep this document terse but to illustrate important points through examples. The TAG expects that additional documents such as the TAG findings will provide more background, motivation, and examples.

Readers will benefit from familiarity with the Requests for Comments (RFC) series from the IETF, some of which define pieces of the architecture discussed in this document.

The architecture described in this document is principally the result of experience. There has been some theoretical and modeling work in the area of Web Architecture, notably Roy Fielding's work on "Representational State Transfer" [REST].

1.2.1. About Properties, Constraints, Principles, and Good Practice Notes

The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in accordance with RFC 2119 [RFC2119].

Some of the principles, practice, etc. may conflict with current practice, in which case education and outreach will be required to improve on that practice. Other items may fill in gaps in published specifications or may call attention to known weaknesses in those specifications.

The motivation behind some good practice notes is economic: there is a benefit to doing things a standard way and a cost to doing things differently. For instance:

  • It is prohibitively expensive to use an identification mechanism other than URIs.
  • It is quite costly to introduce a new URI scheme.
  • It is costly to introduce a new protocol or format.

This document promotes reuse of existing standards when suitable, and gives some guidance on how to innovate (when necessary) in a manner consistent with the Web architecture.

1.2.2. Scope of this Document

This document focuses on the architecture of the Web. The authors assume the reader is familiar with the rationale for some of the general design principles: minimal constraints (fewer rules makes the system more flexible), modularity, minimum redundancy, extensibility, simplicity, and robustness.

Other groups inside and outside W3C are writing down principles related to specialized aspects of Web architecture, including accessibility, internationalization, device independence, and Web Services. The section on Architectural Specifications includes some references.

2. Identification and Resources

Web architecture starts with Uniform Resource Identifiers (URI), whose generic syntax is defined by "Uniform Resource Identifiers (URI): Generic Syntax" [URI]. The Web relies on a worldwide agreement to follow the rules of URIs so that we can refer to things on the Web, access them, describe them, and share them.

URIs identify resources. When people (through representations) refer to a resource with a URI, a link is formed. The networked information system is built of linked resources, and the large-scale effect is a shared information space. The value of the Web increases with the number of linked resources (the "network effect"). The value of a resource also increases when it is identifiable on the Web.


Use URIs: All important resources SHOULD be identified by a URI.2

There are many benefits to making resources identifiable by URI. Some are by design (e.g., linking, bookmarking, and caching), while others have arisen naturally (e.g., global search services).3

2.1. Comparing Identifiers

Communication requires that two parties have a way of knowing they are referring to the same resource. On the Web, if two parties use the same URI, the parties are referring to the same resource. Section 6 of [URI] discusses URI comparison and the determination of URI equivalence. In general, rules for determining URI equivalence come from more than on specification, usually the URI specification, a URI scheme specification, and a protocol specification. Depending on the application, a client may invest more processing effort to reduce the likelihood of a false negative (i.e., two URIs are equivalent but that was not detected).

Clients must not make assumptions about URI equivalence that are not borne out by the relevant specifications. For instance, clients must not assume that http://weather.example.com/Oaxaca and http://weather.example.com/oaxaca identify the same resource, since none of the specifications involved states that that the path part of the URI is case-insensitive. Web servers may vary in how they are configured to handle case-sensitivity.

Though it is possible to determine that two URIs are equivalent, it is never possible to be sure that two URIs identify different resources. Web architecture does not constrain resources to be uniquely named.

Good practice

Spelling URIs: If you want to refer to a resource, and you have been provided with a URI for that purpose, you SHOULD use the spelling of the URI as it was originally provided.

To help parties know when they are referring to the same resource, it follows that URI producers should be conservative about the number of different URIs they produce for the same resource. For instance, a URI producer should not advertise (without cause) that http://weather.example.com/Oaxaca and http://weather.example.com/oaxaca refer to the same resource, as clients will not detect the equivalence relationship. See section 6.3 of [URI] for further advice on how to reduce the risk of false negatives.

Note that a URI does not, in general, provide information about the nature of the resource it identifies. In our travel scenario, the example URI (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, agents must not rely on the URI string to communicate the meaning of a resource. A site reporting the weather in Oaxaca could just as easily be identified by the URI http://vjc.example.com/315. And the URI http://weather.example.com/vancouver might identify the resource "my old car." See the section on retrieving a representation for information about how the meaning of a resource is conveyed.

Editor's note: When finding available on URI opacity, link from here.

2.2. URI Schemes

Each URI begins with a scheme name (the string before the first ":") that refers to a specification for assigning identifiers within that scheme. As such, the URI syntax is a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme. For instance, a URI scheme might specify the type of resource identified by such URIs, the desired persistence of such URIs, or a default character encoding for URIs of that scheme. Furthermore, the URI scheme specification is the first one used to determine how to dereference the URI.

For example the scheme of the URI http://weather.example.com/ is "http", and for ftp://ftp.example.com/ it is "ftp". It is common to classify URIs by scheme, calling the two preceding examples respectively an "HTTP URI" and an "FTP URI".

Several URI schemes incorporate identification mechanisms that pre-date the Web into this syntax:

Other URI schemes have been introduced since the advent of the Web, including those introduced as a consequence of new protocols. Examples of URIs for these schemes include:

The Internet Assigned Numbers Authority (IANA) registry [IANASchemes] maintains the mapping between URI scheme names and their specifications. For instance, the IANA registry indicates that the "http" scheme is defined by [RFC2616]. The process for registration of new URI schemes is defined by RFC2717.

Since many aspects of URI processing are scheme-dependent, and since a huge range of already deployed software is expected to be able to process URIs, the cost of introduction of new URI schemes is quite high.

Good practice

New URI schemes: Authors of specifications SHOULD avoid introducing new URI schemes when existing schemes can be used to meet the goals of the specifications.

Consider our travel scenario: should the 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 Architecture allows the definition of new schemes, there is a cost to registration and especially deployment of new schemes. When a client dereferences such as URI, if what really happens is that HTTP GET is invoked to retrieve an HTML representation of the resource, then an HTTP URI would have sufficed. If a URI scheme exists that meets the needs of an application, designers should use it rather than invent one. Furthermore, designers should expect that it will prove useful to be able to share a URI across applications, even if that utility is not initially evident.

If the motivation behind registering a new scheme is to allow a client to launch a particular application when retrieving a representation, such dispatching can be accomplished at lower expense by registering a new MIME type instead. Reasons for this include:

Editor's note: When finding available based on Tim Bray's discussion of this topic, link from here.

The use of unregistered URI schemes is discouraged for a number of reasons:

2.3. URI Authority

Many URI schemes include a hierarchical element for a naming authority (the string between "//" and the next "/"), such that governance of the name space defined by the remainder of the URI is delegated to that authority (which may, in turn, delegate it further). The generic syntax provides a common means for distinguishing an authority based on a registered domain name or server address. See section 3.2 of [URI] for more information about the authority portion of a URI.

How authority is delegated depends on the URI scheme. The deployment and use of different URI schemes may require varying degrees of central coordination and administration. For example, MAILTO, FTP, and HTTP URIs depend (in practice at least) on the use of the DNS infrastructure; see "ICP-1: Internet Domain Name System Structure and Delegation" [IANAICP1] for more information about how the IANA manages delegation of domain names. For information about work on a central registry for URNs, see "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database" [RFC3403].

Successful communication between two parties about a piece of information relies on shared understanding of the meaning of the information. On the Web, thousands of independent parties can identify and communicate about a Web resource. To give these parties the confidence that they are all talking about the same thing when they refer to "the resource identified by the following URI ..." the design choice for the Web is, in general, that the owner of a resource assigns its authoritative meaning and the URIs that refer to it. See the draft TAG finding "Client handling of MIME headers" for more discussion of this topic.

In our travel scenario, the authority over the HTTP URI http://weather.example.com/oaxaca and the meaning of the resource it designates is delegated to the managers of weather.example.com.

2.4. Fragment Identifiers

The fragment identifier component of a URI (the string after the "#") allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information that is selective with respet to that resource. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource that is merely named with respect to the primary resource. Like the primary resource, the meaning of the secondary resource is determined by the authority responsible for the URI.

Although the generic URI syntax allows any URI to end with a fragment identifier, some URI schemes do not define the semantics of fragment identifiers. For instance, fragment identifier semantics are not defined for MAILTO URIs.

For URI schemes that do support fragment identifiers, the semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of the retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. The presence of a fragment identifier component in a URI does not imply that a retrieval action will take place.

Fragment identifier semantics may differ among formats. For instance, in XHTML, fragment identifiers are specified via the id attribute and refer to hypertext anchors. In the Resource Description Framework [RDF10], fragments can be used to identify anything, be it abstract (e.g., a dream) or concrete (e.g., an automobile).

Suppose that in our travel scenario the server returns an XHTML representation when Dan dereferences the URI http://weather.example.com/oaxaca. Then, by navigating within the XHTML content, Dan finds that the URI http://weather.example.com/oaxaca#t34 refers to information about the temperature in Oaxaca. The resource owner has appropriately made the meaning of the secondary resource consistent with the meaning of the primary resource.

Interpretation of the fragment identifier during a retrieval action is performed solely by the client; the fragment identifier is not passed to other systems during the process of retrieval. Thus, there are some advantages to using a URI without a fragment identifier: only URIs work with intermediaries in the Web architecture (e.g., proxies) or with redirection (in HTTP [RFC2616], for example).

2.4.1. Fragment identifiers and content negotiation

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 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 client and the server engage in HTTP content negotiation, so that Dan receives the best image format his client can handle. The URI 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. This URI makes sense for the SVG representation, since SVG defines fragment identifier semantics. However, the URI does not make sense for the PNG and JPEG/JFIF representations; those specifications do not define fragment identifier semantics.

Good practice

Content negotiation with fragments: Authors SHOULD NOT use HTTP content negotiation for different media types that do not share the same fragment identifier semantics.

2.5. Dereferencing a URI

Given a URI, a system may attempt to perform a variety of operations on the resource, as might be characterized by such words as "denote", "access", "update", "replace", or "find attributes". Such operations are defined by the formats and protocols that make use of URIs. The URI specification (in [URI], section 1.2.2) defines the following terms related to interactions through a URI.

URI resolution
The process of determining an access mechanism and the appropriate parameters necessary to dereference a URI; such resolution may require several iterations.
URI dereference
To dereference a URI is to use an access mechanism to perform an action on the URI's resource.
Resource retrieval
A URI dereference that causes a client to retrieve a representation of the associated resource.

During URI resolution, an agent applies in succession a finite set of relevant specifications, beginning with the specification of the context in which the URI is found (e.g., a format or protocol specification, or an application). Any one of these specifications may define more than one access mechanism (e.g., the HTTP protocol defines a number of access methods, including GET, HEAD, and POST). Note that the information governing the choice of access mechanism may be found in the context, not the URI itself (e.g., the choice of HTTP GET v. HTTP HEAD).

Some URI schemes do not define dereference mechanisms. The URN scheme [RFC 2141] does not specify a dereference procedure, although [RFC 3401] describes a dereference system for URNs.

TAG issue metadataInURI-31: Should metadata (e.g., versioning information) be encoded in URIs?

TAG issue siteDate-26: Web site metadata improving on robots.txt, w3c/p3p and favicon etc.

2.5.1. Retrieving a Representation

One of the most important actions on the Web is to retrieve a representation of a resource (by using, for example, HTTP GET). As mentioned above, the authority responsible for a URI determines what the URI identifies and which representations are used for interaction with the resource. The representations communicate the meaning of the resource.

Good practice

Resource descriptions: Owners of important resources SHOULD make available representations that describe the nature and purpose of those resources.

As an example of dereferencing a URI to retrieve a representation, suppose that http://weather.example.com/oaxaca is used within an a element of an SVG document. The sequence of specifications applied is:

  1. The SVG 1.0 Recommendation [SVG10], which imports the link semantics defined by XLink 1.0 [XLink10]. Section 17.1 of the SVG specification suggests that interaction with an a link involves retrieving a representation of a resource, identified by the XLink href attribute: "By activating these links (by clicking with the mouse, through keyboard input, and voice commands), users may visit these resources."
  2. The URI specification [URI], which states that the URI scheme (here, "http") may further restrict the syntax and semantics of identifiers using that scheme."
  3. The HTTP/1.1 protocol. Section 3.2.2 of RFC2616 [RFC2616] explains the semantics of "http" scheme URIs. The GET method defined in HTTP/1.1 is used to retrieve the representation of the resource.
  4. Once the representation has been retrieved, the media type of the representation governs its interpretation (here, for rendering).

Note that, in general, one cannot determine the media type(s) of representation(s) of a resource by inspecting a URI for that resource. For example, do not assume that a URI that ends with the string ".html" refers to a resource that has an HTML representation.

2.5.2. Safe Retrieval

Dan's retrieval of weather information qualifies as a "safe" interaction; a safe request is a read-only query or lookup. Other Web interactions resemble orders more than queries. These "unsafe" operations cause a change to the state of a resource. Unsafe operations include subscription services, posting to a list, or modifying a database.

Safe interactions are important because these are interactions where users can browse with confidence and where software programs (e.g., search engines and browsers that pre-cache data for the user) can follow links safely. Users (or software agents acting on their behalf) do not commit themselves to anything by querying a resource or following a link.


Safe retrieval: Agents do not incur obligations by retrieving a representation.

For instance, suppose in our travel scenario that the managers of weather.example.com offer a monthly newsletter available by subscription. It is incorrect and harmful to publish a page that states "By following this link, you can subscribe to the Oaxaca Newsletter and you also indicate that you agree to the following terms and conditions..." This approach does not account for the fact that anyone (in particular, a search service or a proxy) can follow this link (or another one elsewhere with the same URI), and anyone who follows those links may never have seen the terms and conditions.

For more information about safe and unsafe operations using HTTP GET and POST, and handling security concerns around the use of HTTP GET, see the draft TAG finding "URIs, Addressability, and the use of HTTP GET and POST."

2.6. URI Persistence

The value of a URI increases with the predictability of interactions with that URI.

Good practice

URI Persistence: Parties responsible for a URI SHOULD service that URI predictably and consistently.

Service breakdowns include:

There are strong social expectations that once a URI identifies a particular resource, it should continue indefinitely to refer to that resource; this is called the persistence of the URI. URI persistence is always a matter of policy and commitment on the part of authorities servicing URIs rather than a constraint imposed by technological means.

URI persistence also improves when ambiguity is removed about what the URI identifies. For instance, saying that the URI http://www.example.com/moby identifies "Moby Dick" can lead to confusion because this might be interpreted as any one of the following very distinct resources: a particular printing of this work (say, by ISBN), or the work itself in an abstract sense (for example, using RDF), or the fictional white whale, or a particular copy of the book on the shelves of a library (via the Web interface of the library's online catalog), or the record in the library's electronic catalog which contains the metadata about the work, or the Gutenberg project's online version. Similarly, one should not use the same URI to refer to a person and to that person's mailbox.

Ambiguous descriptions of what a URI identifies increase the likelihood that two parties will think the same URI identifies different resources, and thus that the parties will use the URI inconsistently. This can be costly, as in the case of two databases in which the same URI is used inconsistently; merging the two databases might lead to confusion or errors.

HTTP [RFC2616] has been designed to help service URIs. For example, HTTP redirection (via some of the 3xx response codes) permits servers to tell a client that further action needs to be taken by the client in order to fulfill the request (e.g., the resource has been assigned a new URI). In addition, content negotiation also promotes consistency, as a site manager would not be required to define new URIs for each new format that is supported, as would be the case with protocols that don't support content negotiation, such as FTP.

For more discussion about URI persistence, refer to [Cool].4

2.7. Access Control

As we have seen, identification of a resource on the Web is distinct from interacting with that resource. It is reasonable to control access to the resource (e.g., for security reasons), but it is unreasonable to prohibit others from merely identifying the resource.

As an analogy: A building might have a policy that the public may only enter via the main front door, and only during business hours. People employed in the building and in making deliveries to it might use other doors as appropriate. Such a policy would be enforced by a combination of security personnel and mechanical devices such as locks and pass-cards. One would not enforce this policy by hiding some of the building entrances, nor by requesting legislation requiring the use of the front door and forbidding anyone to reveal the fact that there are other doors to the building.

In the travel scenario, imagine that Dan and Norm both subscribe to the weather.example.com newsletter. Dan wishes to point out an article of particular interest to Norm, using a URI. The managers of weather.example.com can offer Dan and Norm the benefits of URIs (e.g., bookmarking and linking) and still control access to the newsletter by authorized parties. The Web provides several mechanisms to control access to resources, none of which relies on hiding or suppressing URIs for those resources. For more information on identification and access control, please refer to the TAG finding "'Deep Linking' in the World Wide Web."

2.8. Future Directions for Identifiers

2.8.1. Internationalized identifiers

The integration of internationalized identifiers (i.e., composed of characters beyond those allowed by [URI]) into the Web Architecture is an important and open issue. See TAG issue IRIEverywhere-27 for discussion about work going on in this area.

2.8.2. Determination of Resource Equivalence

Emerging Semantic Web technologies, including "DAML+OIL" [DAMLOIL] and "Web Ontology Language (OWL)" [OWL10], define RDF properties such as equivalentTo and FunctionalProperty to state -- or at least claim -- formally that two URIs identify the same resource.

2.8.3. Conversion of fragment identifiers among different media types

There has been some discussion but no agreement that new access protocols should provide a means to convert fragment identifiers according to media type.

2.8.4. Non-hierarchical administration

One area of work involves the creation of globally unique identifiers in a file-sharing system without centralized or hierarchical administration.

3. Representations

A representation is data that represents or describes the state of a resource. It consists of:

  1. Electronic data expressed in one or more formats (e.g., XHTML, CSS, PNG, XLink, RDF/XML, and SMIL animation) used separately or in combination.
  2. Metadata about the representation, such as the Internet Media Type (defined in RFC 2046 [RFC2046]). The Internet Media Type is the key to the correct interpretation of a resource representation, and governs the handling of fragment identifiers. When transferred by a Web protocol, a representation often includes metadata about both the representation and the message bearing the representation (for example, some HTTP headers).

Web agents use representations to modify as well as read resource state.

3.1. Relation to MIME headers

As discussed above, the owner of a resource assigns its authoritative meaning and the URIs that refer to it. This meaning is communicated in part through metadata that is part of the representation, notably the Internet Media Type. At times there may be inconsistencies between metadata and what is specified in a format. Examples of inconsistencies between headers and format data that have been observed on the Web include:

Clients should detect such inconsistencies but should not resolve them without involving the user (e.g., by securing permission or at least providing notification). Clients must not silently ignore authoritative server metadata.

See the draft TAG finding "Client handling of MIME headers" for more in-depth discussion and examples.

3.2. Characteristics of formats and format specifications

The Web can be used to interchange resource representations in any format. This flexibility is important, since there is continuing progress in the development of new data formats for new applications and the refinement of existing ones.

For a format to be usefully interoperable between two parties, the parties must have a shared understanding of its syntax and semantics. This is not to imply that a sender of data can count on constraining its treatment by a receiver; simply that making good use of electronic data usually requires knowledge of its designers' intentions.

For a format to be widely interoperable across the Web:

Although the Web architecture allows for the deployment of new data formats, the creation and deployment of new formats (and software able to handle them) can be very expensive. Thus, before inventing a new data format, designers should carefully consider re-using one that is already available. For example, if a format is required to contain human-readable text with embedded hyperlinks, it is almost certainly better to use HTML for this purpose than to invent a new format.

3.2.1. Desirable Characteristics of Format Specifications

As noted above, the utility of data formats starts with the availability of a normative specification. Some of the desirable characteristics of a format include:

Attention to Programmer Needs
A specification that is written to meet the needs of programmers is more likely to be implemented, and thus more likely to be useful. In particular, the specification SHOULD be in part formal and mathematical, rather than relying exclusively on narrative.
Attention to Author Needs
Formats that allow authors to intuitively and efficiently address problems they are trying to solve, that can be readily learned, that are simple to use, and that are interoperable are more likely to be adopted by authors and authoring tool developers.
Attention to User Needs
A number of characteristics of a format specification will address the needs of end users, and doing so will create a market for the format. Attention to issues of accessibility, internationalization, and device-independence will tend to make a format specification more flexible.
Attention to Error-Handling
Given that representations are generated by humans (either coded directly or mediated by an authoring tool) and then transmitted in a heterogeneous network, it is inevitable that errors will occur. Specifications of data formats SHOULD be clear about behavior in the presence of errors. It is reasonable to specify that errors should be worked around, or should result in the termination of a transaction or session. It is not acceptable for the behavior in the face of errors to be left unspecified. See the draft TAG finding "Client handling of MIME headers" for more discussion about error reporting.
Issue errorHandling-20
Information hiding
When designing specifications that address independent functions of a system, references between the specifications are in general harmful. They are harmful because they impede the independent evolution of the specifications.
For example, it is a strength of XML that XPath cannot query the HTTP header. It is a strength of HTTP that it does not refer to details of the underlying TCP to the extent that it cannot be run over a different transport service. Similarly, the RDF data graph has a significance that is independent of the actual serialization.
Sometimes it is necessary (and good for given application) to break layers. For example, it is good for an HTTP client to be aware of TCP speeds and round trip times to different mirror servers in order to optimize the choice of server. When designing specification, identify the functionalities that break layers so it is clear when they are being used.

The section on architectural specifications includes references to additional format specification guidelines.

Other design issues:

3.2.2. Taxonomic Categorization of Data Formats

This section discusses important characteristics of data formats which can together be used to describe and understand them. Binary v. Textual

A textual data format is one in which the data is specified as a linear sequence of characters. HTML, Internet e-mail, and all XML-based languages are textual. In modern textual data formats, the characters are usually taken from the Unicode repertoire.

Binary data formats are those in which portions of the data are encoded for direct use by computer processors, for example thirty-two bit little-endian two's-complement and sixty-four bit IEEE double-precision floating-point. The portions of data so represented are include numeric values, pointers, and compressed data of all sorts.

In principle, all data can be represented using textual formats.

The trade-offs between binary and textual data formats are complex and application-dependent. Binary formats can be substantially more compact, particularly for complex pointer-rich data structures. Also, they can be consumed more rapidly by software in those cases where they can be loaded into memory and used with little or no conversion.

Textual formats are often more portable and interoperable, since there are fewer choices for representation of the basic units (characters), and those choices are well-understood and widely implemented.

Textual formats also have the considerable advantage that they can be directly read and understood by human beings. This can simplify the tasks of creating and mainting processing software, and allow the direct intervention of humans in the processing chain without recourse to tools any more complex than the ubiquitous text editor. Finally, it simplifies the necessary human task of learning about new data formats (the "View Source" effect).

All things being equal (a rare state of affairs) textual formats are generally preferable to binary ones in Web applications.

It is important to emphasize that intuition as to such matters as data size and processing speed are not a reliable guide in data format design; quantitative studies are essential to a correct understanding of the trade-offs.

TAG issue binaryXML-30: Effect of Mobile on architecture - size, complexity, memory constraints. Binary infosets, storage efficiency. Final-form v. Reusable

Final-form data formats are not designed to allow modification or uses other than that intended by their designers. An example would be PDF, which is designed to support the presentation of page images on either screen or paper, and is not readily used in any other way. XSL Formatting Objects (XSL-FO) share this characteristic.

XHTML, on the other hand, can be and is put to a variety of uses including direct display (with highly flexible display semantics), processing by network-sensitive Web spiders to support search and retrieval operations, and reprocessing into a variety of derivative forms.

In general XML-based data formats are more re-usable and repurposable than the alternatives, although the example of XSL-FO shows that this is not an absolute.

There are many cases where final-form is an application requirement; representations which embody legally-binding transactions are an obvious example. In such cases, the use of digital signatures may be appropriate to achieve immutability, whether the format is naturally final-form or some XML vocabulary.

On the other hand, where such requirements are not in play, representations that are reusable and repurposable are in general higher in value, particularly in the case where the information's utility may be long-lived. Composable v. Standalone

Some data formats are explicitly designed to be used in combination with others, while some are designed for standalone use. An example of a standalone data format is PDF; it is not typically embedded in representations encoded in other formats.

At the other extreme is SOAP, which is designed explicitly to contain a "payload" in some non-SOAP vocabulary. Another example is SVG, which is designed to be included in compound documents, and which may in turn contain information encoded in other XML vocabularies.

This characteristic is related to, but distinct from, the final-form/reusable distinction discussed above. For example, one can certainly imagine cases where it is useful for a representation to include data in multiple different formats, but be considered immutable and display-only.

TAG issue xmlProfiles-29: When, whither and how to profile W3C specifications in the XML Family?

TAG issue mixedUIXMLNamespace-33: Composability for user interface-oriented XML namespaces

TAG issue xmlFunctions-34: XML Transformation and composability (e.g., XSLT, XInclude, Encryption)

TAG issue RDFinXHTML-35: Syntax and semantics for embedding RDF in XHTML Extensibility
  1. Versioning
  2. Backward compatibility
  3. Forward compatibility
  4. Optional v. mandatory extensions
  5. Schema restriction if designing for extensibility. Deterministic/non-deterministic content models

More incoming from D. Orchard

Editor's note: Expect to add reference Web Architecture: Extensible Languages.

3.2.3. Presentation, Content, and Interaction

In many cases, the information contained in a separation is logically separable from the choice of ways in which it may be presented to a human, and the modes of interaction it may support.

While such separation is, where possible, often advantageous, it is clearly not always possible and in some cases not desirable either.

More incoming from C. Lilley

3.2.4. Embedding Hyperlinks in Representations

The Web's vast network of hyperlinks is one of its defining characteristics, and resource representations are thus commonly required to contain embedded links to other resources.

This section assumes that the other resources identified by hyperlinks are represented by URI references, a basic requirement of Web Architecture. There are, however, many syntactic options available for embedding such URI-based hyperlinks in resource representations.

More incoming from N. Walsh

TAG issue: What is the scope of using XLink? xlinkScope-23.

3.3. XML-Based Representations

Many resource representations are encoded in formats which are XML vocabularies. This section discusses issues that are specific to such data formats.

Anyone seeking guidance in this area is urged to consult the "Guidelines For The Use of XML in IETF Protocols" [IETFXML] for the use of XML in Internet Protocols. This document contains a very thorough discussion of the considerations that govern whether or not XML ought to be used, as well as specific guidelines on how it ought to be used. While it is directed at Internet applications with specific reference to protocols, the discussion is generally applicable to Web scenarios as well.

The discussion here should be seen as ancillary to the content of the IETF BCP. Refer also to "XML Accessibility Guidelines" [XAG] for help designing XML formats that lower barriers to Web accessibility for people with disabilities.

3.3.1. When to Use an XML-Based Format

XML defines textual data formats that are naturally suited to describing data objects which are hierarchical and processed in an in-order sequence. It is widely but not universally applicable for format specifications. For example, an audio or video format is unlikely to be well suited to representation in XML. Design constraints that would suggest the use of XML include:

  1. Explicit representation of a hierarchical structure.
  2. The data's usefulness should outlive the tools currently used to process it.
  3. Ability to support internationalization in a self-describing way that makes confusion over coding options unlikely.
  4. Early detection of encoding errors with no requirement to "work around" such errors.
  5. A high proportion of human-readable textual content.
  6. Potential composition of the data format with other XML-encoded formats.

Editor's note: Which XML Specifications make up the XML Family?

3.3.2. XML Namespaces

The Web is significantly a networked information system. Authors and applications can use URIs uniformly to identify different resources on the Web. After representations of these resources have been retrieved, they may be processed in a variety of ways. Some applications (and some users) will undoubtably build new resources by combining several representations together. This is particularly easy, and potentially useful, when XML representations are available for all the resources.

However, combining representations in this way moves them out of their original context and places them in a new context. This change of context introduces the possibility of information loss. Any information that depended on the local context will no longer be available.

What is needed is a mechanism for establishing a global context for the elements and attributes in the XML resources. This problem bears a strong resemblance to the distinction between relative and absolute URIs. While the many hundreds of relative URI references to "index.html" on a typical web server may be entirely unambiguous in their respective contexts, they have no unambiguous global meaning. But each such relative URI has an unambiguous absolute URI that can be established in its local context and used when a document is moved. This solves the problem for URI references.

For elements and attributes, their names can be seen as analogous to relative URI. Within their original context, they have meanings that are clear and entirely unambiguous. Namespaces in XML provides a mechanism for establishing a globally unique name that can be understood in any context.

The "absolute" form of an XML element or attribute name is the combination of its namespace URI and its local name. This is represented lexically in documents by associating namespace names with (optional) prefixes and combining prefixes and local names with a colon as described in "Namespaces in XML" [XMLNS].

Designers that use namespaces are thus providing a global context for documents authored with their schema. Establishing this global context allows their documents (and portions of their documents) to be reused and combined in novel ways not yet imagined. Failure to provide a namespace makes such reuse more difficult, perhaps impractical in some cases.

The most significant technical drawback to using namespaces is that they do not interact well with DTDs. DTDs perform validation based on the lexical form of the name, making prefixes semantically significant in ways that are not desirable. As other schema language technologies become widely deployed, this drawback will diminish in significance.

3.3.3. Namespace Documents

Namespace designers SHOULD make available human-readable material to meet the needs of those who will use the namespace vocabulary. The simplest way to achieve this is for the namespace name to be an HTTP URI which may be dereferenced to access this material. The resource identified by such a URI is called a "namespace document."

There are many reasons why a person or agent might want more information about the namespace. A person might want to:

  • understand its purpose,
  • find out who controls it,
  • request authority to access schemas or collateral material about it, or
  • report a bug or situation that could be considered an error in some collateral material.

A namespace document should also support the automatic retrieval of other Web resources that support the processing markup from this vocabulary. Useful information to processors includes:

  • schemas, to use for validation,
  • stylesheets, to use for presentation,
  • ontologies, to use for making inferences, or
  • any number of other application-specific details.

It follows that there is, in general, no single type of resource that can be returned in response to a request for the namespace name that will always be the most appropriate; see the section on future work regarding namespace document formats for more information.

Issue: namespaceDocument-8: What should a "namespace document" look like?

Issue: abstractComponentRefs-37: Definition of abstract components with namespace names and frag ids

Editor's note: Where should we put a section on mixing namespaces; is the section on processing model more appropriate? See issue mixedUIXMLNamespace-33.

3.3.4. Fragment identifiers and ID semantics

Suppose that the URI http://example.com/oaxaca defines a resource with representations encoded in XML. What, then, is the interpretation of the URI http://example.org/oaxaca#weather?

The URI specification [URI] makes it clear that the interpretation depends on the context of the media type of the representation. It follows from this that designers of XML-based data formats SHOULD include the semantics of fragment identifiers in their designs. The XPointer Framework [XPTRFR] provides a syntax designed for in such fragment identifiers, and it SHOULD be used for this purpose.

When a representation is provided whose media type is application/xml, there are no semantics defined for fragment identifiers, and thus they SHOULD NOT be provided for such representations. This is also the case if the representation is known to be XML because the media type has a suffix of +xml as described in "XML Media Types" [RFC3023], but there is no normative specification of fragment semantics.

It is common practice to assume that when an element has an attribute that is declared in a DTD to be of type ID, then the fragment identifier #abc identifies the element which has an attribute of that type whose value is "abc". However, there is no normative support for this assumption and it is problematic in practice, since the only defined way to establish that an attribute is of type ID is via a DTD, which may not exist or may not be available.

TAG issue fragmentInXML-28: Do fragment identifiers refer to a syntactic element (at least for XML content), or can they refer to abstractions? See TAG issue.

TAG issue xmlIDSemantics-32: How should the problem of identifying ID semantics in XML languages be addressed in the absence of a DTD? See draft TAG finding "How should the problem of identifying ID semantics in XML languages be addressed in the absence of a DTD?".

3.3.5. Media Types for XML

RFC 3023 defines the media types application/xml and text/xml, and describes a convention whereby XML-based data formats use media types with a +xml suffix, for example image/svg+xml.

In general, media types beginning with text/ SHOULD NOT be used for XML representations. They create two problems: First, intermediate agents in the Web are allowed to "transcode", i.e., convert one character encoding to another. Since XML documents are designed to allow them to be self-describing, and since this is a good and widely-followed practice, any such transcoding will make the self-description false.

Secondly, representations whose media types begin with text/ are required, unless the charset parameter is specified, to be considered to be encoded in US-ASCII. In the case of XML, since it is self-describing, it is good practice to omit the charset parameter, and since XML is very often not encoded in US-ASCII, the use of "text/" media types effectively precludes this good practice.

3.4. Future Directions for Representations

3.4.1. Namespace document formats

The Resource Directory Description Language [RDDL] is a proposal under discussion in the community for a variant of XHTML optimized for the construction of namespace documents which meet the goals described in this section. Note, however, that RDDL or a document like it, is no more universally correct than any other type of representation. Namespace developers should give careful consideration to choosing the most appropriate format for their application, keeping in mind that both human- and machine-readable information is useful.

4. Interaction

Incoming replacement text expected from R. Fielding.

As mentioned in the introduction, the Web is designed to create the large-scale effect of a shared information space that scales well and behaves predictably. It is not static - it is primarily used by people to get information, and that process is not one of passive consumption. Besides selecting which documents to read, people also interact with them - scrolling, zooming, filling in forms, following hyperlinks, and viewing and interacting with animations and scripting. A document is thus not merely a piece of XML markup and associated stylesheet but also descriptions of hyperlinking, scripting through the Document Object Model, declarative animation, associated audio and visual media, forms, etc.

4.1. Device Independence and Multimodal Interaction

Although much interaction to date has taken place through fairly similar desktop and laptop computers - with a keyboard, mouse, sctreen - increasingly interaction also uses other devices - PDSa, cellphones, spoken interaction - and also using accessibility helpers ranging from screen magnifiers through to Braille devices. The increasing necessity for such multimodal interaction informs the architectural principles and best practices relating to Web interaction.

4.2. HTTP and REST

Good practice

Understand REST: Designers of protocols SHOULD invest time in understanding the REST paradigm and consider the role to which its principles could guide their design:
  • statelessness
  • clear assignment of roles to parties
  • uniform address space
  • limited, uniform set of verbs

4.3. Ideas and Issues

  1. Consistency of media types and message contents (from the TAG finding "Internet Media Type registration, consistency of use"
  2. Consistency of communicating character encoding (same source).
  3. HTTP as a substrate protocol [TAG issue HTTPSubstrate-16]
  4. Several of these protocols share a reliance on the Multipurpose Internet Mail Extensions (MIME) standards for the format of message bodies [RFC2045] and for Internet Media Types [RFC2046].

4.4. Future Directions for Interactions

Currently empty

5. Glossary

Glossary not yet completed.

5.1. Principles, Constraints, etc.

Editor's note: The TAG is still experimenting with the categorization of points in this document. This list is likely to change. It has also been suggested that the categories clearly indicate their primary audience.

The important points of this document are categorized as follows:

An architectural constraint is a restriction in behavior or interaction within the system. Constraints may be imposed for technical, policy, or other reasons.
Design Choice
In the design of the Web, some design choices, like the names of the <p> and <li> elements in HTML, or the choice of the colon character in URIs, are somewhat arbitrary; if <par>, <elt>, or * had been chosen instead, the large-scale result would, most likely, have been the same. Other design choices are more fundamental; these are the focus of this document.
Good practice
Good practice -- by software developers, content authors, site managers, users, and specification writers -- increases the value of the Web.
An architectural principle is a fundamental law that applies to a large number of situations and variables. Architectural principles include "separation of concerns", "generic interface", "self-descriptive syntax," "visible semantics," "network effect" (Metcalfe's Law), and Amdahl's Law: "The speed of a system is determined by its slowest component."
Architectural properties include both the functional properties achieved by the system, such as accessibility and global scope, and non-functional properties, such as relative ease of evolution, reusability of components, efficiency, and dynamic extensibility.

6. References

6.1. Normative References

Editor's note: The usage of a normative reference in this document needs clarification.

IANA's online registry of URI Schemes is available at http://www.iana.org/assignments/uri-schemes.
Dan Connolly's list of URI schemes is a useful resource for finding out which references define various URI schemes.
IANA's online registry of MIME types is available at http://www.iana.org/assignments/media-types/index.html.
IETF "RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed, N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2045.txt.
IETF "RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N. Freed, N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2046.txt.
IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.
"Uniform Resource Identifiers (URI): Generic Syntax" (T. Berners-Lee, R. Fielding, L. Masinter, Eds.) is currently being revised. The IETF Internet Draft draft-fielding-uri-rfc2396bis-03 is expected to obsolete RFC 2396, which is the current URI standard. "Architecture of the World Wide Web" uses the concepts and terms defined by draft-fielding-uri-rfc2396bis-03, preferring them to those defined RFC 2396. The TAG is tracking the evolution of draft-fielding-uri-rfc2396bis-03.
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.
IETF "Registration Procedures for URL Scheme Names", R. Petke, I. King, November 1999. Available at http://www.ietf.org/rfc/rfc2717.txt.

6.2. Architectural Specifications

"Authoring Tool Accessibility Guidelines 1.0," J. Treviranus, C. McCathieNevile, I. Jacobs, and J. Richards, eds., 3 February 2000. This W3C Recommendation is http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
"Character Model for the World Wide Web," M. Dürst and F. Yergeau, eds., 30 April 2002. This W3C Working Draft is http://www.w3.org/TR/2002/WD-charmod-20020430/. The latest version is available at http://www.w3.org/TR/charmod/.
"Device Independent Principles," R. Gimson, Ed., 18 September 2001. This W3C Working Draft is http://www.w3.org/TR/2001/WD-di-princ-20010918/. The latest version is available at http://www.w3.org/TR/di-princ/.
"Principled Design of the Modern Web Architecture", R.T. Fielding and R.N. Taylor, UC Irvine. In Proceedings of the 2000 International Conference on Software Engineering (ICSE 2000), Limerick, Ireland, June 2000, pp. 407-416. This document is available at http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf.
IETF "RFC 1958: Architectural Principles of the Internet", B. Carpenter, June 1996. Available at http://www.ietf.org/rfc/rfc1958.txt.
"QA Framework: Specification Guidelines," D. Hazaël-Massieux, L. Henderson, L. Rosenthal, D. Dimitriadis, K. Gavrylyuk, eds., 10 February 2003.This W3C Working Draft is http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/ The latest version is available at http://www.w3.org/TR/qaframe-spec/.
"User Agent Accessibility Guidelines 1.0," I. Jacobs, J. Gunderson, E. Hansen, eds., 17 December 2002. This W3C Recommendation is http://www.w3.org/TR/2002/REC-UAAG10-20021217/.
"Web Content Accessibility Guidelines 1.0," W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 5 May 1999. This W3C Recommendation is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
"Web Services Architecture," D. Booth, M. Champion, C. Ferris, F. McCabe, E. Newcomer, D. Orchard eds., 14 May 2003. This W3C Working Draft is http://www.w3.org/TR/2003/WD-ws-arch-20030514/. The latest version of this document is available at http://www.w3.org/TR/ws-arch/.
"XML Accessibility Guidelines", D. Dardailler, S. Palmer, C. McCathieNevile, 3 October 2002. This W3C Working Draft is http://www.w3.org/TR/2002/WD-xag-20021003. The latest version is available at http://www.w3.org/TR/xag.

6.3. Non-Normative References

"Universal Resource Identifiers - Axioms of Web Architecture", T. Berners-Lee, living document dated December 1996. Available at http://www.w3.org/DesignIssues/Axioms.
"Cool URIs don't change" T. Berners-Lee, W3C, 1998 Available at http://www.w3.org/Provider/Style/URI.
"Cascading Style Sheets, level 2", B. Bos, H. Lie, C. Lilley, I. Jacobs, 12 May 1998. This W3C Recommendation is available at http://www.w3.org/TR/1998/REC-CSS2-19980512/.
"DAML+OIL (March 2001) Reference Description", D. Connolly, F. van Harmelen, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, 18 Dec 2001. This W3C Note is available at http://www.w3.org/TR/2001/NOTE-daml+oil-reference-20011218.
"Knowledge-Domain Interoperability and an Open Hyperdocument System", D. C. Engelbart, June 1990.
"Fragment Identifiers on URIs", T. Berners-Lee, living document dated April 1997. Available at http://www.w3.org/DesignIssues/Fragment.
"HTML 4.01 Specification", D. Raggett, A. Le Hors, I. Jacobs, 24 December 1999. This W3C Recommendation is available at http://www.w3.org/TR/1999/REC-html401-19991224/.
IANA's ICP-1: Internet Domain Name System Structure and Delegation (ccTLD Administration and Delegation) is available at http://www.icann.org/icp/icp-1.htm.
Dan Connolly's list of URI schemes is a useful resource for finding out which references define various URI schemes.
IETF "Guidelines For The Use of XML in IETF Protocols," S. Hollenbeck, M. Rose, L. Masinter, eds., 2 November 2002. This IETF Internet Draft is available at http://www.imc.org/ietf-xml-use/xml-guidelines-07.txt. If this document is no longer available, refer to the ietf-xml-use mailing list.
IETF " Internationalized Resource Identifiers (IRIs)", M. Duerst, M. Suignard, Nov 2002. This IETF Internet Draft is available at http://www.w3.org/International/iri-edit/draft-duerst-iri.html. If this document is no longer available, refer to the home page for Editing 'Internationalized Resource Identifiers (IRIs)'.
"Web Ontology Language (OWL) Reference Version 1.0", M. Dean, D. Connolly, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, L. A. Stein, eds., 12 Nov 2002. This W3C Working Draft is available at http://www.w3.org/TR/2002/WD-owl-ref-20021112/.
"The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", M. Marchiori, ed., 16 April 2002. This W3C Recommendation is available at http://www.w3.org/TR/2002/REC-P3P-20020416/.
"Resource Directory Description Language (RDDL)", J. Borden, T. Bray, eds., 14 February 2003. This document is available at http://www.tbray.org/tag/rddl/rddl3.html.
"Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. R. Swick, eds., 22 February 1999. This W3C Recommendation is available at http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.
" Representational State Transfer (REST)", Chapter 5 of "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Thesis of R. T. Fielding, 2000. Available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.
IETF "RFC 2141: URN Syntax", R. Moats, May 1997. Available at http://www.ietf.org/rfc/rfc2141.txt.
IETF "Guidelines for new URL Schemes", L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, November 1999. Available at: http://www.ietf.org/rfc/rfc2718.txt.
IETF "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, January 2001. Available at: http://www.rfc-editor.org/rfc/rfc3023.txt
IETF "RFC 3236: The 'application/xhtml+xml' Media Type", M. Baker, P. Stark, January 2002. Available at: http://www.rfc-editor.org/rfc/rfc3236.txt
IETF "RFC 3401: Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", M. Mealing, October 2002. Available at: http://www.rfc-editor.org/rfc/rfc3401.txt
IETF "RFC 3403: Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", M. Mealing, October 2002. Available at: http://www.rfc-editor.org/rfc/rfc3403.txt
"Scalable Vector Graphics (SVG) 1.1 Specification", J. Ferraiolo, Fujisawa Jun, D. Jackson, eds., 14 January 2003. This W3C Recommendation is available at http://www.w3.org/TR/2003/REC-SVG11-20030114/.
" IAB Technical Comment on the Unique DNS Root", B. Carpenter, 27 Sep 1999. Available at http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm.
"XHTML 1.0: The Extensible HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0", S. Pemberton et al., 26 January 2000, revised 1 August 2002. Available at http://www.w3.org/TR/2002/REC-xhtml1-20020801/.
"XML Linking Language (XLink) Version 1.0", S. DeRose, E. Maler, D. Orchard, 27 June 2001. This W3C Recommendation is available at http://www.w3.org/TR/2001/REC-xlink-20010627/.
"Extensible Markup Language (XML) 1.0 (Second Edition)", T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler, 6 October 2000. This W3C Recommendation is available at http://www.w3.org/TR/2000/REC-xml-20001006.
"Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14 Jan 1999. This W3C Recommendation is available at http://www.w3.org/TR/1999/REC-xml-names-19990114/.
"XPointer Framework", P. Grosso, E. Maler, J. Marsh, N. Walsh, eds., 25 March 2003. This W3C Recommendation is available at http://www.w3.org/TR/2003/REC-xptr-framework-20030325/.
"W3C Process Document", 19 July 2001 Version. Available at http://www.w3.org/Consortium/Process-20010719/.

7. End Notes

  1. @@Text here on why SMTP part of Web@@ (Note 1 context.)
  2. This principle dates back at least as far as Douglas Engelbart's seminal work on open hypertext systems; see section Every Object Addressable in [Eng90]. (Note 2 context.)
  3. See the TAG finding "URIs, Addressability, and the use of HTTP GET" for some details about the interaction of this principle in HTTP application design. (Note 3 context.)
  4. The title is somewhat misleading. It's not the URIs that change, it's what they identify. (Note 4 context.)

8. Acknowledgments

The authors of this document are the participants of W3C's Technical Architecture Group: Tim Berners-Lee (Chair, W3C), Tim Bray (Antarctica Systems), Dan Connolly (W3C), Paul Cotton (Microsoft), Roy Fielding (Day Software), Chris Lilley (W3C), David Orchard (BEA Systems), Norman Walsh (Sun), and Stuart Williams (Hewlett-Packard).

The TAG thanks people for their thoughtful contributions on the TAG's public mailing list, www-tag (archive).