Architecture of the World Wide Web, First Edition

List of Principles, Constraints, and Good Practice Notes

The following principles, constraints, and good practice notes are discussed in this document and listed here for convenience. There is also a free-standing summary.

Identification

• Global Identifiers (principle, (principle, 2)
• Identify with URIs (practice, (practice, 2.1)
• URIs Identify a Single Resource (constraint, 2.2)
• Avoiding URI aliases (practice, 2.3.1)
• Consistent URI usage (practice, (practice, 2.3.1)
• Reuse URI schemes (practice, 2.4)
• URI opacity (practice, 2.5)

Interaction

• Reuse representation formats (practice, 3.2)
• Data-metadata inconsistency (constraint, 3.3)3.4)
• Metadata association (practice, 3.3)3.4)
• Safe retrieval (principle, (principle, 3.4)3.5)
• Available representation (practice, 3.5)3.6)
• Reference does not imply dereference (principle, 3.5)3.6)
• Consistent representation (practice, 3.5.1)3.6.1)

Data Formats

• Version information (practice, (practice, 4.2.1)
• Namespace policy (practice, (practice, 4.2.2)
• Extensibility mechanisms (practice, 4.2.3)
• Extensibility conformance (practice, 4.2.3)
• Unknown extensions (practice, 4.2.3)
• Separation of content, presentation, interaction (practice, 4.3)
• Link identification (practice, (practice, 4.4)
• Web linking (practice, 4.4)
• Generic URIs (practice, 4.4)
• Hypertext links (practice, (practice, 4.4)
• Namespace adoption (practice, (practice, 4.5.3)
• Namespace documents (practice, 4.5.4)
• QNames Indistinguishable from URIs (constraint, 4.5.5)
• QName Mapping (practice, (practice, 4.5.5)
• XML and "text/*" (practice, (practice, 4.5.7)
• XML and character encodings (practice, 4.5.7)

General Architecture Principles

• Orthogonality (principle, (principle, 5.1)
• Error recovery (principle, (principle, 5.3)

1.1. About this Document

This document describes the properties we desire of the Web and the design choices that have been made to achieve them. It promotes the reusere-use of existing standards when suitable, and gives guidance on how to innovate in a manner manner consistent with Web architecture.

The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in the principles, constraints, and good practice notes in accordance with RFC 2119 [RFC2119].

This However, this document does not include include conformance provisions for these reasons:

• Conforming software is expected to be so diverse that it would not be useful to be able to refer to the class of conforming software agents.
• Some of the good practice notes concern people; specifications generally define conformance for software, not people.
• We do not believe that theThe addition of a conformance section is not likely to increase the utility of the document.

2.1. Benefits of URIs

The choice of syntax for global identifiers is somewhat arbitrary; it is their global scope that is important. important. The Uniform Resource Identifier, [URI], currently being revised) has been been successfully deployed since the creation of the Web. There are substantial benefits to participating in the existing network of URIs, URIs, including linking, bookmarking, caching, and indexing by search engines, and there are substantial costs to creating a new identification system that has the same properties as URIs.

A resource should have an associated URI if another party might reasonably want to create a hypertext link to it, make or refute assertions about it, retrieve or cache a representation of it, include all or part of it by reference into another representation, annotate it, or perform other operations on it. Software developers should expect that sharing URIsa URI across applications will be useful, even if that utility is not initially evident. The TAG finding "URIs, Addressability, and the use of HTTP GET and POST" discusses additional benefits and considerations of URI addressability.

Note: Good Some URIpractice: schemes (such asURIs the "ftp" URI scheme specification) useincrease the term "designate"value where thisthe World document uses "identify."

2.3. URI Comparisons

URIsURI that are identical, character-by-character, refer to the same resource. Since Web Architecture allows the association of multiple URIs with a given resource, two URIs that are not character-by-character identical may still refer to the same resource. Different URIs do not necessarily refer to different resources but there is generally a higher computational cost to determine that multiple different URIs refer to the same resource.

To reduce the risk of a false negative (i.e., an incorrect conclusion that two URIs do not refer to the same resource) or a false positive (i.e., an incorrect conclusion that two URIs do refer to the same resource), some specifications describe equivalence tests in addition to character-by-character comparison. For example, for "http" URIs, the authority component (the part after "//" and before the next "/") is defined to be case-insensitive. Thus, the "http" URI specification allows agents to conclude that authority components in two "http" URIs identify the same resource when those strings are character-by-character comparison.equivalent or differ only by case. Agents that reach conclusions based on comparisons that are not licensed by the relevant specifications take responsibility for any problems that result; see the section on error handling (§5.3)[section 5.3] for more information about about responsible behavior when reaching unlicensed conclusions. Section Section 6 of [URI] provides more more information about comparing URIs and reducing the risk of false negatives and positives.

See alsothe section below on approaches other than string comparison that allow different agents the assertion that two URIs identify the same resource resource (§2.7.2)2.7.2] .

2.4. URI Schemes

In the URI "http://weather.example.com/", the "http" that appears before the colon (":") names a URI scheme. Each URI scheme has a specification that explains the scheme-specific specific details of how scheme identifiers are allocated and become associated with a resource. The URI syntax is thus a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers within that scheme.

Examples of URIs from various schemes include:

• mailto:joe@example.org
• ftp://example.org/aDirectory/aFile
• news:comp.infosystems.www
• tel:+1-816-555-1212
• ldap://ldap.example.org/c=GB?objectClass?one
• urn:oasis:names:tc:entity:xmlns:xml:catalog

While Web architecture allows the definition of new schemes, introducing a new scheme is costly. Many Many aspects of URI processing are scheme-dependent, and a large amount of deployed software already processes URIs of well-known schemes. Introducing a new URI scheme requires the development and deployment not only of client software to handle the scheme, but also of ancillary agents such as gateways, proxies, and caches. See See [RFC2718] for other considerations and costs related to URI scheme design.

Because of these costs, if a URI scheme exists that meets the needs of an application, designers should use it rather than invent one.

Consider our travel scenario: should the agent 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". When a software agent dereferences such a URI, if what really happens is that HTTP GET is invoked to retrieve a representation of the resource, then an "http" URI would have sufficed. If the motivation behind registering a new scheme is to allow a software agent to launch a particular application when retrieving a representation, such dispatching can be accomplished at lower expense via Internet media types. When designing a new data format, the appropriate mechanism to promote its deployment on the Web is the Internet media type. Media types also provide a means for building new information space applications [section 4.6] , described below.

2.5. URI Opacity

It is tempting to guess the nature of a resource by inspection of a URI that identifies it. However, the Web is designed so that agents communicate resource information state through representations, not identifiers. In general, one cannot determine the Internet media type of representations of a resource representation by inspecting a URI for that resource. For example, the ".html" at the end of "http://example.com/page.html" provides no guarantee that representations of the identified resource will be served with the Internet media type "text/html". The publisher is free to allocate identifiers and define how they are served. The HTTP protocol does not constrain the Internet media type based on the path component of the URI; the URI owner is free to configure the server to return a representation using PNG or any other data format.

Resource state may evolve over time. Requiring a URI owner to publish a new URI for each change in resource state would lead to a significant number of broken references. For robustness, Web architecture promotes independence independence between an identifier and the state of the identified resource.

In practice, a small number of inferences can be made because they are explicitly licensedspecified by the relevant specifications. Some of these inferences are discussed in the details of retrieving a representation (§3.1.1).

The example URI used in the travel scenario ("http://weather.example.com/oaxaca") suggests to a human reader that the identified resource has something to do with the weather in Oaxaca. 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 photo album."

On the other hand, the URI "mailto:joe@example.com" "mailto:joe@example.com" indicates that the URI refers to a mailbox. The "mailto" URI scheme specification authorizes agents to infer that URIs of this form identify Internet mailboxes.

Some URI assignment authorities document and publish their URI assignment policies. For more information about URI opacity, see TAG issues metaDataInURI-31 and siteData-36.

2.6. Fragment Identifiers

The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations. The terms "primary resource" and "secondary resource" are defined in section 3.5 of [URI].

The terms “primary” and “secondary” in this context do not limit the nature of the resource—they are not classes. In this context, primary and secondary simply indicate that there is a relationship between the resources for theinterpretation purposes of one URI: the URI with a fragment identifier. Any resource can be identified as aidentifiers secondary resource. It might also be identified using a URI without a fragment identifier, and a resource may be identified as a secondary resource via multiple URIs. The purpose of these terms is to enable discussion of the relationship between such resources, not to limit the nature of a resource.

The interpretation of fragment identifiers is discussed in the section on media types and fragment identifier semantics (§3.2.1).

See TAG issue abstractComponentRefs-37, which concerns the use of fragment identifiers with namespace names to identify abstract components. components.

2.7. Future Directions for Identifiers

There remain open questions regarding identifiers on the Web. The following sections identify a few areas of future work in the Web community.

3.1. Using a URI to Access a Resource

Agents may use a URI to access the referenced resource; this is called dereferencing the URI. Access may take many forms, including retrieving a representation of the resource (for instance, by using HTTP GET or HEAD), adding or modifying a representation of the resource (for instance, by using HTTP POST or PUT, which in some cases may change the actual state of the resource if the submitted representations are interpreted as instructions to that end), and deleting some or all representations of the resource (for instance, by using HTTP DELETE, which in some cases may result in the deletion of the resource itself).

There may be more than one way to access a resource for a given URI; application context determines which access method an agent uses. For instance, a browser might use HTTP GET to retrieve a representation of a resource, whereas a hypertext link checker might use HTTP HEAD on the same URI simply to establish whether a representation is available. Some URI schemes set expectations about available access methods, others (such as the URN scheme [RFC 2141]) do not. Section 1.2.2 of [URI] discusses the separation of identification and interaction in more detail. For more information about relationships between multiple access methods and URI addressability, see the TAG finding "URIs, Addressability, and the use of HTTP GET and POST".

Although many URI schemes (§2.4) are named after protocols, this does not imply that use of such a URI will necessarily result in access to the resource via the named protocol. Even when an agent uses uses a URI to retrieve a representation, that access might be through through gateways, proxies, caches, and name resolution services that are independent of the protocol associated with the scheme name.

Many URI schemes define a default interaction protocol for attempting access to the identified resource. That interaction protocol is often the basis for allocating identifiers within that scheme, just as "http" URIs are defined in terms of TCP-based HTTP servers. However, this does not imply that all interaction with such resources is limited to the default interaction protocol. For example, information retrieval systems often make use of proxies to interact with a multitude of URI schemes, such as HTTP proxies being used to access "ftp" and "wais" resources. Proxies can also to provide enhanced services, such as annotation proxies that combine normal information retrieval with additional metadata retrieval to provide a seamless, multidimensional view of resources using the same protocols and user agents as the non-annotated Web. Likewise, future protocols may be defined that encompass our current systems, using entirely different interaction mechanisms, without changing the existing identifier schemes. See also, principle of orthogonal specifications (§5.1).