W3C

Architectural Principles of the World Wide Web

W3C Working Draft 29 Oct 2002

This version:
http://www.w3.org/2001/tag/2002/WD-webarch-20021029
Previous version:
http://www.w3.org/TR/2002/WD-webarch-20020830/
Latest TAG draft:
http://www.w3.org/2001/tag/webarch/
Latest TR page draft:
http://www.w3.org/TR/webarch/
Editor:
Ian Jacobs, W3C
Authors:
See acknowledgments.

Copyright © 2002 W3C ® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.

Abstract

The World Wide Web is a networked information system. Web Architecture is the set of principles that all agents in the system follow to create the large-scale effect of a shared information space. Identification, data formats, and protocols are the main technical components of Web Architecture, but the large-scale effect depends on social behavior as well.

This document strives to establish a reference set of principles 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 draft incorporates comments on the first public Working Draft of "Architectural Principles of the World Wide Web." This document has been developed by W3C's Technical Architecture Group (TAG) (charter). A list of changes in this document is available.

This draft remains incomplete; sections 1 and 2 are the most developed, 3 and 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.

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

1. Introduction

The World Wide Web (or, Web) is a networked information system consisting of agents (programs acting on behalf of another person, entity, or process) that exchange information.

This architecture consists of:

  1. Identifiers. A single specification that defines identifiers for objects in the system: the Uniform Resource Identifier (URI) [RFC2396].
  2. Formats. A nonexclusive set of data format specifications designed for interchange between agents in the system. This includes several data formats used separately or in combination (e.g., XHTML, CSS, PNG, XLink, RDF/XML, SMIL animation), as well as technologies for building new data formats (XML, XML Namespaces).
  3. Protocols. A small and nonexclusive set of protocol specifications for interchanging information between agents, including HTTP [RFC2616], FTP, SMTP1, and others. 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].

1.1. Structure and conventions of this document

After this introduction, sections two, three, and four discuss identifiers, formats, and protocols, respectively. Each section highlights principles of Web architecture and notes on good practice. These principles and good practice notes are summarized at the end of the introduction.

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

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.

1.2. Requirements, Principles, and Constraints

@@Explain here how requirements and principles lead to constraints.@@

The principles in this document are based on 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.3. Audience of this document

The intended audience for this document includes:

  1. Participants in W3C groups,
  2. Other groups and individuals developing technologies to be integrated into the Web.

The authors have made every effort to keep this document terse, with the expectation that additional documents will elaborate on the principles.

1.4. Scope of this document

This document focuses on architectural principles specific to or fundamental to the Web. It does not address general principles of design, which are also important to the success of the Web. Indeed, behind many of the principles of Web Architecture lie these and other principles such as minimal constraint (fewer rules makes the system more flexible), modularity, minimum redundancy, extensibility, simplicity, and robustness.

Other groups within W3C are addressing architectural design goals in the following areas:

  1. Internationalization; see W3C's Internationalization Activity.
  2. Accessibility; see W3C's Web Accessibility Initiative.
  3. Device independence; see W3C's Device Independence Activity.

For information about architectural principles of the Internet, refer to [RFC1958].

1.5. Summary of principles

In the design of the Web, some design decisions, like the names 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 architectural principles of the Web:

Use URIs:
All important resources SHOULD be identified by a URI.
URI ambiguity:
Ambiguity in the relationship between URIs and resources is harmful for humans and machines.
Resource descriptions:
Owners of important resources (for example, Internet protocol parameters) SHOULD make available representations that describe the nature and purpose of those resources.
Safe retrieval:
Agents do not incur obligations by retrieving a representation.
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.
Unregistered URI schemes:
Unregistered URI schemes MUST NOT be used on the public Internet for general purpose applications.

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

1.6. Summary of good practice notes

This document suggests the following good practice:

URI case:
It SHOULD NOT be assumed that URIs which differ only in character case can be used interchangeably.
Coneg with fragments:
Authors SHOULD NOT use HTTP content negotiation for different media types that do not share the same fragment identifier semantics.

2. Identifiers and resources

The Web is a universe of resources. A resource is defined by [RFC2396] to be anything that has identity. Examples include documents, files, menu items, machines, and services, as well as people, organizations, and concepts. Web architecture starts with a uniform syntax for resource identifiers, so that we can refer to resources, access them, describe them, and share them. The Uniform Resource Identifier (URI) syntax employs an extensible set of URI schemes. Several URI schemes incorporate into this syntax some identification mechanisms that pre-date the Web:

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:

One can append a fragment identifier to a URI to yield an identifier for part of, or a view of, a resource2:

Note that while this composition is syntactically fully general, it is meaningless in some URI schemes. The URI mailto:nobody@example.org#abc is meaningless in practice.

A generic syntax for URIs is defined by [RFC2396]. The current document uses the term "URI" to mean, in RFC2396 terms, an absolute URI reference3 optionally followed by a fragment identifier. The TAG is working actively to convince the IETF to revise RFC2396 so that the definition of "URI" aligns with the current document.

2.1. Resources, URIs, and the shared information space

When one resource refers to another via a URI, a link is formed. When many resources are linked this way, the large-scale effect is a shared information space, addressable by URI. The value of the Web increases with the number of resources addressable by URI. In turn, resources are more valuable when they are addressable in the Web. Hence:

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

There are many benefits to making resources addressable by URI. Some are by design (e.g., linking and bookmarking), while others have arisen naturally (e.g., global search services). 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.

2.2. Operations on URIs

The two primary operations on URIs are:

  1. Comparison of identifiers
  2. Interaction with resources

2.2.1. Comparison of identifiers

There may be applications (e.g., XML namespace names [XMLNS]) where comparison is expected to be the sole or primary operation on a URI. Certain URI schemes provide rules for determining the syntactic equivalence of URIs, i.e., whether two URIs are different spellings of the same identifier. These rules vary from scheme to scheme.

For example, URNs begin with two colon-delimited fields, the first of which is the string urn and the second identifies the subclass of URN, for example urn:ietf:example. In URNs, these two fields are to be compared in a case-insensitive fashion. The remainder of the URN following the second colon is subject to rules dependent on the content of the second field (following the first colon) - thus the equivalence rules may vary within URN namespace identifiers.

Section 3.2.3 of the HTTP specification [RFC2616] states that, when comparing two HTTP URIs, the host name part must be considered case-insensitive, so http://WWW.EXAMPLE/ and http://www.example/ identify the same resource.

Good practice note. URI case: It SHOULD NOT be assumed that URIs which differ only in character case can be used interchangeably.

Note: Equivalence of URIs is not the same as consistent representations of a resource.

Issue: URIEquivalence-15: When are two URI variants considered equivalent? See also issue IRIEverywhere-27 - Should W3C specifications start promoting IRIs?

2.2.2. Interactions with resources

To dereference a URI is to interact with the resource it identifies. One interacts with a resource by the exchange of representations of resource state; a representation is a data object that represents or describes a resource state. A resource is an abstraction for which there is a conceptual mapping to a (possibly empty) set of representations. Representations, when transferred by a Web protocol, are often accompanied by metadata in the message (for example, HTTP headers). In particular, the value of the media type metadata value is key to the correct interpretation of a resource representation, and governs the handling of fragment identifiers.

For instance, suppose the URI http://weather.yahoo.com/forecast/MXOA0069 identifies a resource that is "the weather forecast for Oaxaca, Mexico". A representation retrieved by means of that URI may be encoded in any number of formats, including HTML, XHTML, and SVG; see section 2 for more information about formats.

Interaction with a resource is governed by successive application of a finite set of specifications, beginning with the specification that governs the scheme of the URI. For example, suppose the URI for the weather forecast is used within an a element of an SVG document. The sequence of specifications applied is:

  1. The URI specification [RFC2396]. This specification says (in section 3.1) that the scheme "define the semantics for the remainder of the URI string." In this case, the URI scheme is HTTP.
  2. The HTTP/1.1 protocol. Section 3.2.2 of RFC2616 [RFC2616] explains the semantics of HTTP URIs.
  3. The SVG 1.0 Recommendation [SVG10], which imports the link semantics defined by XLink 1.0 [XLink10]. Section 17.4 of the SVG specification suggests that interaction with an a link involves retrieving a representation 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." This means that 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).

2.2.3. Persistence and consistency

It is important for the correct functioning of the Web that the mapping between URIs and resources be unambiguous.

URI ambiguity: Ambiguity in the relationship between URIs and resources is harmful for humans and machines.

The representations of a resource may vary as a function of factors including time, the identity of the agent accessing the resource, data submitted to the resource when interacting with it, and changes external to the resource. For example, for the resource "the weather forecast for Oaxaca, Mexico," the representations depend on (at least) time, the expressed preference of the user for Fahrenheit or Celsius, the identity of the user-agent software receiving the representation, and, presumably, the weather in Oaxaca.

Since one interacts with a resource through its representations, ambiguity can manifest itself in a number of ways:

  1. No representation is available.
  2. Different representations over time are so inconsistent as to create confusion.
  3. There is inconsistency among representations expected to express a strong degree of "sameness" (e.g., a PNG image and a JPEG served as equivalents through HTTP content negotiation, but that represent very different images).

This does not mean that representations of a resource cannot change over time, only that indiscriminate reuse of identifiers undermines their value and interferes with people who relied on them.

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. Persistence is always a matter of policy and commitment on the part of authorities assigning URIs rather than a constraint imposed by technological means.

For example, each W3C technical report (e.g., "the SVG specification") is in fact a series of documents that mature over time (from Working Drafts, Candidate Recommendations, Proposed Recommendations, to Recommendation). W3C assigns a URI to the "latest version" in the series (e.g., http://www.w3.org/TR/SVG). W3C also assigns a URI for each specification in the series (called the "this version URI", e.g., http://www.w3.org/TR/2001/PR-SVG-20010719/). W3C policy is that representations of the "latest version" resource will change over time (with each new publication of an SVG specification). W3C policy is also that representations of a specification designated by a "this version" identifier will not change over time, to the best of W3C's ability to maintain its archives intact.

HTTP [RFC2616] has been designed to help site managers maintain the relationship between a URI and a resource (e.g., through redirects).

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

2.2.4. Retrieving a representation

Depending on the protocol used, there may be several ways to dereference a URI. One of the most important operations for the Web is to retrieve a representation of a resource (such as with HTTP GET), which means to retrieve a representation of the state of the resource. There are other ways to interact with a resource (such as with HTTP POST). Dereference mechanisms vary by URI scheme. For instance, the URN scheme [RFC 2141] does not guarantee that a dereference procedure is defined for any given URN.

Resource descriptions: Owners of important resources (for example, Internet protocol parameters) SHOULD make available representations that describe the nature and purpose of those resources.

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

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

For instance, a user does not incur an obligation by following an HTML link that causes the user agent to retrieve a representation. Tools such as proxies and search engines can retrieve representations without user interaction; it would be harmful to the Web if such operations incurred obligations. See the TAG finding "URIs, Addressability, and the use of HTTP GET" for more information about safe retrieval.

Issue: deepLinking-25: What to say in defense of principle that deep linking is not an illegal act?

Editor's note: Need to say something about difference between assertions about a resource and assertions about a representation. E.g., do not use the same URI to refer to the resource "Moby Dick" and to the particular representation of that resource, or do not use the same URI to refer to a person and to that person's mailbox. See issue httpRange-14.

2.3. URI Schemes

One important characteristic of a URI is its scheme (the string that precedes the first colon in a URI). For example the scheme of the URI http://www.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".

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

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.

While "myscheme:blort" is a URI that satisfies the syntactic constraints of [RFC2396], if "myscheme" is not registered, you do not have license to use that URI in any Internet protocols; there are no valid uses of it. You can't expect anybody to know what you mean by it, and you are not guaranteed that somebody else isn't already using it for something else.

Unregistered URI schemes: Unregistered URI schemes MUST NOT be used on the public Internet for general purpose applications.

The IANA registry [IANASchemes] lists registered URI schemes and the specifications that define them. For instance, the IANA registry indicates that the "http" scheme is defined by [RFC2616]. Refer to RFC2717 for information about registering a new 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. Also, there is a central registry of URN subclasses6.

2.4. Fragment identifiers

In some URI schemes it is meaningful for a URI to end with a fragment identifier. The fragment identifier is interpreted only after the retrieval of a representation. Section 4.1 of [RFC2396] states that "the format and interpretation of fragment identifiers is dependent on the media type [RFC2046] of the retrieval result," that is, the representation.

For instance, if the representation is an HTML document, the fragment identifies a hypertext anchor. In the case of a graphics format, the fragment might identify a circle or spline. 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).

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

Editor's note: 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.5. Some generalities about URIs

The following generalities about URIs are included to answer some frequently asked questions about URIs. Some of these generalities do not hold for all URI schemes.

  1. The authority over a URI determines which resource it identifies.
  2. It is not possible to inspect a URI and determine what resource it identifies. For example, in general, one cannot look at http://www.example.com/lj45sr and know that it refers to "my old car" or "the weather forecast for Oaxaca."

    Over time, we trust that some URIs will identify familiar resources, but that trust derives from social behavior, not the spelling of the identifier.

  3. Several different URIs can identify the same resource.
  4. It is possible to compare two URIs to see whether they are spelled equivalently; see the section on comparison of identifiers for more details.
  5. It is not possible to inspect two URIs that are spelled differently and determine whether they identify the same resource. This does not prevent some URI schemes from mandating equivalence for particular sets of URIs using that scheme.
  6. It is not possible to inspect a URI and know the media type of representation(s) of 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. Of course, resource owners should not publish URIs likely to cause confusion.

3. Formats

Data on the Web manifests itself through resource representations. A resource representation consists of:

  1. An Internet Media Type
  2. A sequence of bits

A format specification describes the structure of the bit sequence.

Refer to other W3C format guidelines: Charmod, XAG, etc.

3.1. Scope

What is a format, and how does it relate to the concept of a document. Do all documents have a format? Is a document a collection of resources of different formats organized into a whole? Is a document the same as a resource? the same as a message body? as a non-multipart message body? What is the distinction between documents and data, if any. Does 'document' imply human readable and if so, does it imply presentation? Does it imply a hierarchically structured, report-like document with headings and subheadings? Is a catalog a document? Is a rave flyer a document?

Negotiation (stuff above might go here also) by network request, by listed alternatives in content any preference? Resource variants, foo.css and foo.html unlikely to be equivalent.

3.2. Processing model

On the interpretation and processing of formats (see namespaceDocument-8 and mixedNamespaceMeaning-13):

3.3. Specification design guidelines

@@Incomplete sections on specification design.@@

3.3.1. When to use XML

  1. Persistence; there is lots of redundancy
  2. Internationalization
  3. Clean error-handling; early detection of errors
  4. Mix of structure and text content
  5. Composability

On using XML:

3.3.2. Information hiding

When designing specifications that address independent functions of a system, avoidable 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 do 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. However, there is a flaw: the embedded XML parsetype="Literal" data type.

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.

3.3.3. Content, Presentation, and Interaction

This section attempts to organize some areas of future discussion. Separating the concepts content, presentation, and interaction allows more easily composable specifications. For example, a markup language can be specified independently of a style sheet language. The separation facilitates alternate presentations of the same content, which is seen to have an accessibility advantage and to be more suited to the multiple modalities of Web access.

Issue: contentPresentation-26: Separation of semantic and presentational markup, to the extent possible, is architecturally sound.

3.3.3.1. Content

Composability (ns-meaning). Use of XML for tree structured content. Linking in general v. idref in one document. Human readable v. machine data. Served or not (hidden behind server - semantic firewall, accessibility. Linking into parts of the content, transclusion of parts. Compound documents, components from multiple servers - scalability, deep linking. Processing models, error handling.

3.3.3.2. Presentation

Presentation by decoration (application of CSS to XML as presentation), and by derivation (creation of html/svg/etc as presentation). Linking (bidirectionally) between content and presentations. Inheritance of properties across namespaces. Consistency of property names. Subsets. 'Applies to' as opposed to 'set on'. Specificity of properties as attributes, chaining styling, restyling. Time-lines, linking to portions of a time-line.

3.3.3.3. Interaction

Animation, scripting, events, client/server interaction. Declarative v. script based - accessibility, power; formalization of common functionality (loop animation, rollovers) in declarative form. DOM - making additional methods, add to rather than replacing XML DOM. Effect of script/programming language limitations on choice of element and attribute names. Linking to active components - XForms example with model and abstract form control, can be extended to presentational instantiation of form control.

3.4. Ideas and issues

  1. For new format specifications, use XML family of specifications unless there's a good reason not to. Which XML specifications? Which particular family members?
  2. Format designers should use URIs without constraining content providers to particular URI schemes.
  3. Allow for Web-wide linking, not just internal document linking.
  4. Information-hiding is contrary to global identifiers. But specs must be orthogonal: You should not be able to write an xpath to peek into http headers
  5. Namespaces. Issues namespaceDocument-8, mixedNamespaceMeaning-13
  6. Qnames: Issues rdfmsQnameUriMapping-6, qnameAsId-18 and finding "Using QNames as Identifiers in Content"
  7. Formatting properties: Issue formattingProperties-19, contentPresentation-26
  8. Error handling: Issue errorHandling-20
  9. Media type registration: RFC3023Charset-21, finding Internet Media Type registration, consistency of use. Also, makes sure to define fragment identifier semantics.
  10. Effect of Mobile on architecture - size, complexity, memory constraints. Binary infosets, storage efficiency. Composable subsets.
  11. What is the scope of using XLink? xlinkScope-23
  12. Can a specification include rules for overriding HTTP content type parameters? contentTypeOverride-24
  13. Create formats that allow authors to hide URIs from view (e.g., behind link text). For authors: at times it is useful or necessary to reveal a URI (e.g., in an advertisement on the side of a bus), in which case, good social behavior requires that the URI be easy to use.

4. Protocols

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.

4.1. HTTP and REST

4.2. Ideas and issues

  1. Consistency of media types and message contents (from "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]

5. Glossary

Agents
programs acting on behalf of another person, entity, or process
Dereference
To dereference a URI is to interact with the resource it identifies.
Link
When one resource refers to another via a URI, a link is formed.
MIME
standards for the format of message bodies [RFC2045] and for Internet Media Types [RFC2046].
Persistence
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.
Representation
One interacts with a resource by the exchange of representations of resource state; a representation is a data object that represents or describes a resource state.
Resource
A resource is defined by [RFC2396] to be anything that has identity.
Retrieve a representation
to retrieve a representation of the state of the resource.
URI Scheme
One important characteristic of a URI is its scheme (the string that precedes the first colon in a URI).

6. References

6.1. Normative References

IANASchemes
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.
RFC2045
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.
RFC2046
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.
RFC2119
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.
RFC2396
IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. Available at http://www.ietf.org/rfc/rfc2396.txt.
RFC2616
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.
RFC2717
IETF "Registration Procedures for URL Scheme Names", R. Petke, I. King, November 1999. Available at http://www.ietf.org/rfc/rfc2717.txt.

6.2. Non-Normative References

Axioms
"Universal Resource Identifiers - Axioms of Web Architecture", T. Berners-Lee, living document dated December 1996. Available at http://www.w3.org/DesignIssues/Axioms
Cool
"Cool URI's don't change" T. Berners-Lee, W3C, 1998 Available at http://www.w3.org/Provider/Style/URI
CSS2
"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/.
Eng90
"Knowledge-Domain Interoperability and an Open Hyperdocument System", D. C. Engelbart, June 1990.
Fielding
"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.
Fragments
"Fragment Identifiers on URIs", T. Berners-Lee, living document dated April 1997. Available at http://www.w3.org/DesignIssues/Fragment
HTML40
"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/.
P3P10
"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/.
RDF10
"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/.
REST
" Representational State Transfer (REST)", Chapter 5 of "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Thesis of R. T. Fielding, 2000.
RFC1958
IETF "RFC 1958: Architectural Principles of the Internet", B. Carpenter, June 1996. Available at http://www.ietf.org/rfc/rfc1958.txt.
RFC2141
IETF "RFC 2141: URN Syntax", R. Moats, May 1997. Available at http://www.ietf.org/rfc/rfc2141.txt.
RFC2718
"Guidelines for new URL Schemes", L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, November 1999. Available at: http://www.ietf.org/rfc/rfc2718.txt.
RFC3236
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
SVG10
"Scalable Vector Graphics (SVG) 1.0 Specification", J. Ferraiolo, ed., 4 Sep 2001. This W3C Recommendation is available at http://www.w3.org/TR/2001/REC-SVG-20010904/.
UniqueDNS
" IAB Technical Comment on the Unique DNS Root", B. Carpenter, 27 Sep 1999.
XHTML10
"XHTML 1.0: The Extensible HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0", S. Pemberton et al., 26 January 2000. The latest version of this W3C Recommendation is available at http://www.w3.org/TR/xhtml1/.
XLink10
"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/.
XML10
"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.
XMLNS
"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/.
W3CPROCESS
" W3C Process Document", 19 July 2001 Version.

7. End notes

  1. @@Text here on why SMTP part of Web@@ (Note 1 context.)
  2. When comparison is expected to be the sole or primary operation on a URI, it does not matter whether one has chosen a URI with our without a fragment identifier. However, when one expects to interact with a resource, 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, for example). (Note 2 context.)
  3. [RFC2396] defines a URI reference to be either an absolute URI reference or a relative URI reference. The syntax for a relative URI reference is a shortened form of that for an absolute URI reference, where some prefix of the URI is missing and certain path components ("." and "..") have a special meaning when, and only when, interpreting a relative path. For example, in a document whose base URI is http://example/dir1/dir2/file1, the relative URI reference ../file2 is a shortened form of http://example/dir1/file2 and the relative URI reference #abc is a shortened form for http://example/dir1/dir2/file1#abc. (Note 3 context.)
  4. 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 4 context.)
  5. The title is somewhat misleading. It's not the URIs that change, it's what they identify. (Note 5 context.)
  6. URN subclasses are called "namespaces" and are identified by namespace identifiers, or NIDs. (Note 6 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).