Architecture of the World Wide Web, First Edition

1. Introduction

The World Wide Web (WWW, or simply Web) is an information space in which the items of interest, referred to as resources, are identified by global identifiers called Uniform Resource Identifiers (URIs).

A travel scenario is used throughout this document to illustrate typical behavior of Web agents — people or software (on behalf of a person, entity, or process) acting on this information space. Software agents include servers, proxies, spiders, browsers, and multimedia players.

Story

While planning a trip to Mexico, Nadia reads "Oaxaca weather information: 'http://weather.example.com/oaxaca'" in a glossy travel magazine. Nadia has enough experience with the Web to recognize that "http://weather.example.com/oaxaca" is a URI. Given the context in which the URI appears, she expects that it allows her to access weather information. When Nadia enters the URI into her browser:

The browser performs an information retrieval action in accordance with its configured behavior for resources identified via the "http" URI scheme.
The authority responsible for "weather.example.com" provides information in a response to the retrieval request.
The browser displays the retrieved information, which includes hypertext links to other information. Nadia can follow these hypertext links to retrieve additional information.

This scenario illustrates the three architectural bases of the Web that are discussed in this document:

Identification. Each resource is identified by a URI. In this travel scenario, the resource is about the weather in Oaxaca and the URI is "http://weather.example.com/oaxaca".
Interaction. Protocols define the syntax and semantics of messages exchanged by agents over a network. Web agents communicate information about the state of a resource through the exchange of representations. In the travel scenario, Nadia (by clicking on a hypertext link) tells her browser to request a representation of the resource identified by the URI in the hypertext link. The browser sends an HTTP GET request to the server at "weather.example.com". The server responds with a representation that includes XHTML data and the Internet Media Type "application/xml+xhtml".
Formats. Representations are built from a non-exclusive set of data formats, used separately or in combination (including XHTML, CSS, PNG, XLink, RDF/XML, SVG, and SMIL animation). In this scenario, the representation data is XHTML. While interpreting the XHTML representation data, the browser retrieves and displays weather maps identified by URIs within the XHTML.

The following illustration shows the relationship between identifier, resource, and representation.

A resource (Oaxaca Weather Info) is identified by a particular URI and is represented by pseudo-HTML content

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.

This document promotes re-use of existing standards when suitable, and gives guidance on how to innovate in a manner consistent with the Web architecture.

The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in the good practice notes, principles, etc. in accordance with RFC 2119 [RFC2119]. However, this document does not include conformance provisions for at least 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.
The addition a conformance section is not likely to increase the utility of the document.

1.1.1. Audience of this Document

This document is intended to inform discussions about issues of Web architecture. The intended audience for this document includes:

Participants in W3C Activities; i.e., developers of Web technologies and specifications in W3C
Other groups and individuals developing technologies to be integrated into the Web
Implementers of W3C specifications
Web content authors and publishers

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.

1.1.2. Scope of this Document

This document presents the general architecture of the Web. Other groups inside and outside W3C also address specialized aspects of Web architecture, including accessibility, internationalization, device independence, and Web Services. The section on Architectural Specifications includes references.

This document strikes a balance between brevity and precision while including illustrative examples. TAG findings are informational documents that complement the current document by providing more detail about selected topics. This document includes some important material from the findings. Since the findings evolve independently, this document also includes references to approved TAG findings. For other TAG issues covered by this document but without an approved finding, references are to entries in the TAG issues list.

1.1.3. Principles, Constraints, and Good Practice

The important points of this document are categorized as follows:

Constraint: 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.
Principle: An architectural principle is a fundamental rule 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."
Property: 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, re-usability of components, efficiency, and dynamic extensibility.

This categorization is derived from Roy Fielding's work on "Representational State Transfer" [REST]. Authors of protocol specifications in particular should invest time in understanding the REST model and consider the role to which of its principles could guide their design: statelessness, clear assignment of roles to parties, uniform address space, and a limited, uniform set of verbs.

1.2. General Architecture Principles

A number of general architecture principles apply to across all three bases of Web architecture.

1.2.1. Orthogonal Specifications

Identification, interaction, and representation are orthogonal (or, "independent", or "loosely coupled") concepts: an identifier can be assigned without knowing what representations are available, agents can interact with any identifier, and representations can change without regard to the identifiers or interactions that may dereference them.

Orthogonality in specifications facilitates a flexible design that can evolve over time. The fact, for example, that the an image can be identified using a URI without needing any information about the representation of that image allowed PNG and SVG to evolve independent of the specifications that define image elements.

Orthogonal abstractions deserve orthogonal specifications. Specifications should clearly indicate those features that simultaneously access information from otherwise orthogonal abstractions. For example a specification should draw attention to a feature that requires information from both the header and the body of a message.

Although the HTTP, HTML, and URI specifications are orthogonal for the most part, they are not completely orthogonal. Experience demonstrates that where they are not orthogonal, problems have arisen:

The HTML specification includes a protocol extension of sorts: it specifies how a user agent sends HTML form data to a server (as a URI query string). The design works reasonably well, although there are limitations related to internationalization (see the TAG finding "URIs, Addressability, and the use of HTTP GET and POST") and the query string design impinges on the server design. Developers (for example, of [CGI] applications) might have an easier time finding the specification if it were published separately and then cited from the HTTP, URI, and HTML specifications.
The HTML specification allows content providers to instruct HTTP servers to build response headers from META element instances. This is an abstraction violation; the developer community deserves to be able to find all HTTP headers from the HTTP specification (including any associated extension registries and specification updates per IETF process). Perhaps as a result, this feature of the HTML specification is not widely deployed. Furthermore, this design has led to confusion in user agent development. The HTML specification states that META in conjunction with http-equiv is intended for HTTP servers, but many HTML user agents interpret http-equiv='refresh' as a client-side instruction.
Some authors use the META/http-equiv approach to declare the character encoding scheme of an HTML document. By design, this is a hint that an HTTP server should emit a corresponding "Content-Type" header field. In practice, the use of the hint in servers is not widely deployed. Furthermore, many user agents use this information to override the "Content-Type" header sent by the server. This works against the principle of authoritative representation metadata.

1.2.2. Extensibility

The information in the Web and the technologies used to represent that information change over time. Some examples of successful technologies designed to allow change while minimizing disruption include:

the fact that URI schemes are independently specified,
the use of an open set of Internet media types in mail and HTTP to specify document interpretation,
the separation of the generic XML grammar and the open set of XML namespaces for element and attribute names,
Extensibility models in Cascading Style Sheets (CSS), XSLT 1.0, and SOAP
user agent plug-ins

The following applies to languages, in particular the specifications of data formats, of message formats, and URIs. Note: This document does not distinguish in any formal way the terms "format" and "language." Context has determined which term is used.

Language subset: one language is a subset (or, "profile") of a second language if any document in the first language is also a valid document in the second language and has the same interpretation in the second language.

Language extension: one language is an extension of a second language if the second is a language subset of the first (thus, the extension is a superset). Clearly, creating an extension language is better for interoperability than creating an incompatible language.

Ideally, many instances of a superset language can be safely and usefully processed as though they were in the subset language. Languages that exhibit this property are said to be "extensible." Language designers can facilitate extensibility by defining how implementations must handle unknown extensions -- for example, that they be ignored (in some way) or should be considered errors.

For example, from early on in the Web, HTML agents followed the convention of ignoring unknown elements. This choice left room for innovation (i.e., non-standard elements) and encouraged the deployment of HTML. However, interoperability problems arose as well. In this type of environment, there is an inevitable tension between interoperability in the short term and the desire for extensibility. Experience shows that designs that strike the right balance between allowing change and preserving interoperability are more likely to thrive and are less likely to disrupt the Web community. Orthogonal specifications help reduce the risk of disruption.

For further discussion, see the section on versioning and extensibility. See also TAG issue xmlProfiles-29.

1.2.3. Error Handling

Errors occur in networked information systems. The manner in which they are dealt with depends on application context. A user agent acts on behalf of the user and therefore is expected to help the user understand the nature of errors, and possibly overcome them. User agents that correct errors without the consent of the user are not acting on the user's behalf.

Principle: Error recovery

Silent recovery from error is harmful.

To promote interoperability, specifications should set expectations about behavior in the face of known error conditions. Experience has led to the following observations about error-handling approaches.

Protocol designers should provide enough information about the error condition so that a an agent can address the error condition. For instance, an HTTP 404 message ("resource not found") is useful because it allows user agents to present relevant information to users, enabling them to contact the author of the representation that included the (broken) link.
Experience with the cost of building a user agent to handle the diverse forms of ill-formed HTML content convinced the authors of the XML specification to require that agents fail deterministically upon encountering ill-formed content. Because users are unlikely to tolerate such failures, this design choice has pressured all parties into respecting XML's constraints, to the benefit of all.
An agent that encounters unrecognized content may handle it in a number of ways, including as an error; see also the section on extensibility and versioning.
Error behavior that is appropriate for a person may not be appropriate for software. People are capable of exercising judgement in ways that software applications generally cannot. An informal error response may suffice for a person but not for a processor.

See the TAG issues contentTypeOverride-24 and errorHandling-20.

1.2.4. Protocol-based Interoperability

The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the syntax, semantics, and sequence of the messages interchanged. The technology shared among Web agents lasts longer than the agents themselves.

It is common for programmers working with the Web to write code that generates and parses these messages directly. It is less common, but not unusual, for end users to have direct exposure to these messages. This leads to the well-known "view source" effect, whereby users gain expertise in the workings of the systems by direct exposure to the underlying protocols.

2. Identification

Parties who wish to communicate must agree upon a shared set of identifiers and on their meanings. The ability to use common identifiers across communities motivates global identifiers in Web architecture. Thus, Uniform Resource Identifiers ([URI], currently being revised) which are global identifiers in the context of the Web, are central to Web architecture.

Constraint: Identify with URIs

The identification mechanism for the Web is the URI.

A URI must be assigned to a resource in order for agents to be able to refer to the resource. It follows that a resource should be assigned a URI if a third party might reasonably want to 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.

When a representation uses a URI (instead of a local identifier) as an identifier, then it gains great power from the vastness of the choice of resources to which it can refer. The phrase the "network effect" describes the fact that the usefulness of the technology is dependent on the size of the deployed Web.

Resources exist before URIs; a resource may be identified by zero URIs. However, there are many benefits to assigning a URI to a resource, including linking, bookmarking, caching, and indexing by search engines. 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.

The scope of a URI is global; the resource identified by a URI does not depend on the context in which the URI appears (see also the section about URIs in other roles). Of course, what an agent does with a URI may vary. The TAG finding "URIs, Addressability, and the use of HTTP GET and POST" discusses additional benefits and considerations of URI addressability.

Principle: URI assignment

A resource owner SHOULD assign a URI to each resource that others will expect to refer to.

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].

2.1. URI Comparisons

Web architecture allows resource owners to assign more than one URI to a resource.

Constraint: URI uniqueness

Web architecture does not constrain a Web resource to be identified by a single URI.

Thus, URIs that are not identical (character for character) do not necessarily refer to different resources. The most straightforward way of establishing that two parties are referring to the same Web resource is to compare, as character strings, the URIs they are using. URI equivalence is discussed in section 6 of [URI]

Good practice: URI aliases

Resource owners should not create arbitrarily different URIs for the same resource.

URI producers should be conservative about the number of different URIs they produce for the same resource. For example, the parties responsible for weather.example.com should not use both "http://weather.example.com/Oaxaca" and "http://weather.example.com/oaxaca" to refer to the same resource; agents will not detect the equivalence relationship by following specifications. On the other hand, there may be good reasons for creating similar-looking URIs. For instance, one might reasonably create URIs that begin with "http://www.example.com/tempo" and "http://www.example.com/tiempo" to provide access to resources by users who speak Italian and Spanish.

Likewise, URI consumers should ensure URI consistency. For instance, when transcribing a URI, agents should not gratuitously escape characters. The term "character" refers to URI characters as defined in section 2 of [URI].

Good practice: Consistent URI usage

If a URI has been assigned to a resource, agents SHOULD refer to the resource using the same URI, character for character.

Applications may apply rules beyond basic string comparison that are licensed by specifications to reduce the risk of false negatives and positives. For example, for "http" URIs, the authority component is case-insensitive. Agents that reach conclusions based on comparisons that are not licensed by relevant specifications take responsibility for any problems that result. Agents should not assume, for example, that "http://weather.example.com/Oaxaca" and "http://weather.example.com/oaxaca" identify the same resource, since none of the specifications involved states that the path part of an "http" URI is case-insensitive.

See section 6 [URI] for more information about comparing URIs and reducing the risk of false negatives and positives. See the section on future directions for approaches other than string comparison that may allow different parties to assert that two URIs identify the same resource.

2.2. URI Ownership

The requirement for URIs to be unambiguous demands that different agents do not assign the same URI to different resources. URI scheme specifications assure this using a variety of techniques, including:

Hierarchical delegation of authority. This approach, exemplified by the "http" and "mailto" schemes, allows the assignment of a part of URI space to one party, reassignment of a piece of that space to another, and so forth.
Random numbers. The generation of a fairly large random number, used in the "uuid" scheme, reduces the risk of ambiguity to a calculated small risk.
Checksums. The generation of a URI as a checksum based on a data object has similar properties to the random number approach. This is the approach taken by the "md5" scheme.
Combination of approaches. The "mid" and "cid" schemes combine some of the above approaches.

The approach taken for the "http" URI scheme follows the pattern whereby the Internet community delegates authority, via the IANA URI scheme registry [IANASchemes] and the DNS, over a set of URIs with a common prefix to one particular owner. One consequence of this approach is the Web's heavy reliance on the central DNS registry.

Whatever the techniques used, except for the checksum case, the agent has a unique relationship with the URI, called URI ownership. The phrase "authority responsible for a URI" is synonymous with "URI owner" in this document.

The social implications of URI ownership are not discussed here. However, the success or failure of these different approaches depends on the extent to which there is consensus in the Internet community on abiding by the defining specifications. The concept of URI ownership is especially visible in the case of the HTTP protocol, which enables the URI owner to serve authoritative representations of a resource. In this case, the HTTP origin server (defined in [RFC2616]) is the agent acting on behalf of the URI owner.

2.3. URI Ambiguity

Just as a shared vocabulary has tangible value, the ambiguous use of terms imposes a cost in communication. URI ambiguity refers to the use of the same URI to refer to more than one distinct resource.

Good practice: URI ambiguity

Avoid URI ambiguity.

URI ambiguity should not be confused with ambiguity in natural language. The English statement "'http://www.example.com/moby' identifies 'Moby Dick'" is ambiguous because one could understand the phrase "Moby Dick" to refer to distinct resources: a particular printing of this work, or the work itself in an abstract sense, 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.

2.3.1. URIs in other Roles

In Web architecture, URIs identify resources. Outside the bounds of Web architecture specifications, URIs can be useful for other purposes, for example, as database keys. For instance, the organizers of a conference might use "mailto:nadia@example.com" to refer to Nadia. While this usage is not licensed by Web architecture specifications, in the context of the conference, all parties may agree to that local policy and understand one another. Certain properties of URIs, such as their potential for uniqueness, make them appealing as general-purpose identifiers. In the Web architecture, "mailto:nadia@example.com" identifies an Internet mailbox; that is what is licensed by the "mailto" URI scheme specification. The fact that the URI serves other purposes in non-Web contexts does not lead to URI ambiguity. URI ambiguity arises a URI is used to identify two different Web resources.

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 normative specification that explains how identifiers are assigned within that scheme. The URI syntax is thus a federated and extensible naming mechanism 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 the Web architecture allows the definition of new schemes, introducing a new scheme is costly. Many aspects of URI processing are scheme-dependent, and a significant 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 [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.

Good practice: New URI schemes

Authors of specifications SHOULD NOT introduce a new URI scheme when an existing scheme provides the desired properties of identifiers and their relation to resources.

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". 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.

Note that even if an agent cannot process representation data in an unknown format, it can at least retrieve it. The data may contain enough information to allow a user or user agent to make some use of it. When an agent does not handle a new URI scheme, it cannot retrieve a representation.

2.4.1. URI Scheme Registration

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

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

There is no generally accepted way to locate the scheme specification.
Someone else may be using the scheme for other purposes.
One should not expect that general-purpose software will do anything useful with URIs of this scheme; the network effect is lost.

Note: Some URI scheme specifications (such as the "ftp" URI scheme specification) use the term "designate" where the current document uses "identify."

TAG issue siteData-36 is about expropriation of naming authority.

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 state through representations, not identifiers. In general, one cannot determine the Internet Media Type of representations of a resource 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 HTTP protocol does not constrain the Internet Media Type based on the path component of the URI; the server is free to return a representation in PNG or any other data format for that URI.

Resource state may evolve over time. Requiring resource owners to change URIs to reflect resource state would lead to a significant number of broken links. For robustness, Web architecture promotes independence between an identifier and the identified resource.

Good practice: URI opacity

Agents making use of URIs MUST NOT attempt to infer properties of the referenced resource except as licensed by relevant specifications.

The example URI used in the travel scenario ("http://weather.example.com/oaxaca") suggests 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" 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.

In some cases, relevant technical specifications license URI assignment authorities to publish assignment policies. For more information about URI opacity, see TAG issue metaDataInURI-31.

2.6. Fragment Identifiers

Story

When navigating within the XHTML data that Nadia receives as a representation of the resource identified by "http://weather.example.com/oaxaca", Nadia finds that the URI "http://weather.example.com/oaxaca#tom" refers to information about tomorrow's weather in Oaxaca. This URI includes the fragment identifier "tom" (the string after the "#").

The fragment identifier of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional 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. The interpretation of fragment identifiers is discussed in the section on media types and fragment identifier semantics.

See TAG issues abstractComponentRefs-37 and DerivedResources-43.

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.

2.7.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.7.2. Assertion that Two URIs Identify the Same Resource

Emerging Semantic Web technologies, including the "Web Ontology Language (OWL)" [OWL10], define RDF [RDF10] properties such as sameAs to assert that two URIs identify the same resource or functionalProperty to imply it.

3. Interaction

Communication between agents over a network about resources involves URIs, messages, and data.

Story

Nadia follows a hypertext link labeled "satellite image" expecting to retrieve a satellite photo of the Oaxaca region. The link to the satellite image is an XHTML link encoded as <a href="http://example.com/satimage/oaxaca">satellite image</a>. Nadia's browser analyzes the URI and determines that its scheme is "http". The browser configuration determines how it locates the identified information, which might be via a cache of prior retrieval actions, by contacting an intermediary (such as a proxy server), or by direct access to the server identified by the URI. In this example, the browser opens a network connection to port 80 on the server at "example.com" and sends a "GET" message as specified by the HTTP protocol, requesting a representation of the resource identified by "/satimage/oaxaca".

The server sends a response message to the browser, once again according to the HTTP protocol. The message consists of several headers and a JPEG image. The browser reads the headers, learns from the "Content-Type" field that the Internet Media Type of the representation is "image/jpeg", reads the sequence of octets that comprises the representation data, and renders the image.

This section describes the architectural principles and constraints regarding interactions between agents, including such topics as network protocols and interaction styles, along with interactions between the Web as a system and the people that make use of it. The fact that the Web is a highly distributed system affects architectural constraints and assumptions about interactions.

Note: The Web Architecture does not require a formal definition of the commonly used phrase "on the Web." Informally, a resource is "on the Web" when it has a URI and an agent can use the URI to retrieve a representation of it using network protocols (given appropriate access privileges, network connectivity, etc.). See the related TAG issue httpRange-14.

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 resource state (for instance, by using HTTP GET or HEAD), modifying the state of the resource (for instance, by using HTTP POST or PUT), and deleting the resource (for instance, by using HTTP DELETE).

There may be more than one way to access a resource for a given URI; application context determines which access mechanism an agent uses. For instance, a browser might use HTTP GET to retrieve a representation of a resource, whereas a 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 mechanisms, 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 mechanisms and URI addressability, see the TAG finding "URIs, Addressability, and the use of HTTP GET and POST".

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

Dereferencing a URI generally involves a succession of steps as described in multiple independent specifications and implemented by the agent. The following example illustrates the series of specifications that are involved when a user instructs a user agent to follow a hypertext link that is part of an SVG document. In this example, the URI is "http://weather.example.com/oaxaca" and the application context calls for the user agent to retrieve and render a representation of the identified resource.

Since the URI is part of a hypertext link in an SVG document, the first relevant specification is the SVG 1.1 Recommendation [SVG11]. Section 17.1 of this specification imports the link semantics defined in XLink 1.0 [XLink10]: "The remote resource (the destination for the link) is defined by a URI specified by the XLink href attribute on the 'a' element." The SVG specification goes on to state that interpretation of an a element involves retrieving a representation of a resource, identified by the href attribute in the XLink namespace: "By activating these links (by clicking with the mouse, through keyboard input, voice commands, etc.), users may visit these resources."
The XLink 1.0 [XLink10] specification, which defines the href attribute in section 5.4, states that "The value of the href attribute must be a URI reference as defined in [IETF RFC 2396], or must result in a URI reference after the escaping procedure described below is applied."
The URI specification [URI] states that "Each URI begins with a scheme name that refers to a specification for assigning identifiers within that scheme." The URI scheme name in this example is "http".
[IANASchemes] states that the "http" scheme is defined by the HTTP/1.1 specification (RFC 2616 [RFC2616], section 3.2.2).
In this SVG context, the agent constructs an HTTP GET request (per section 9.3 of [RFC2616]) to retrieve the representation.
Section 6 of [RFC2616] defines how the server constructs a corresponding response message, including the 'Content-Type' field.
Section 1.4 of [RFC2616] states "HTTP communication usually takes place over TCP/IP connections." This example does not address that step in the process, or other steps such as Domain Name System (DNS) resolution.
The agent interprets the returned representation according to the data format specification that corresponds to the representation's Internet Media Type (the value of the HTTP 'Content-Type') in the relevant IANA registry [MEDIATYPEREG].

3.2. Messages and Representations

The Web's protocols (including HTTP, FTP, SOAP, NNTP, and SMTP) are based on the exchange of messages. A message may include representation data as well as metadata about the resource (such as the "Alternates" and "Vary" HTTP headers), the representation, and the message (such as the "Transfer-encoding" HTTP header). A message may even include metadata about the message metadata (for message-integrity checks, for instance).

Two important classes of message are those that request a representation of a resource, and those that return the result of such a request. Such a response message (for example, a response to an HTTP GET) includes a representation of the state of the resource. A representation is an octet sequence that consists logically of two parts:

Representation data, electronic data about resource state, expressed in one or more formats used separately or in combination, and
Representation metadata. One important piece of metadata is the Internet Media Type, discussed below.

Agents use representations to modify as well as retrieve resource state. Note that even though the response to an HTTP POST request may contain the above types of data, the response to an HTTP POST request is not necessarily a representation of the state of the resource identified in the POST request.

3.3. Internet Media Type

The Internet Media Type [RFC2046]) of a representation determines which data format specification(s) provide the authoritative interpretation of the representation data (including fragment identifier syntax and semantics, if any). The IANA registry [MEDIATYPEREG] maps media types to data formats.

See the TAG finding "Internet Media Type registration, consistency of use" for more information about media type registration.

3.3.1. Media Types and Fragment Identifier Semantics

Story

In one of his XHTML pages, Dirk links to an image that Nadia has published on the Web. He creates a hypertext link with <a href="http://www.example.com/images/nadia#hat">Nadia's hat</a>. Nadia serves an SVG representation of the image (with Internet Media Type "image/svg+xml"), so the authoritative interpretation of the fragment identifier "hat" depends on the SVG specification.

Per [URI], in order to know the authoritative interpretation of a fragment identifier, one must dereference the URI containing the fragment identifier. The Internet Media Type of the retrieved representation specifies the authoritative interpretation of the fragment identifier. Thus, in the case of Dirk and Nadia, the authoritative interpretation depends on the SVG specification, not the XHTML specification (i.e., the context where the URI appears).

Since a URI with a fragment identifier (e.g., U#F) identifies a secondary resource, to establish which secondary resource U#F identifies, one must retrieve a representation of the resource identified by U, then interpret F within the representation data according to the representation's Internet Media Type.

Interpretation of the fragment identifier during a retrieval action is performed solely by the agent; the fragment identifier is not passed to other systems during the process of retrieval. This means that some intermediaries in the Web architecture (such as proxies) have no interaction with fragment identifiers and that redirection (in HTTP [RFC2616], for example) does not account for them.

Note that one can use a URI with a fragment identifier even if one does not have a representation available for interpreting the fragment identifier (one can compare two such URIs, for example). Parties that draw conclusions about the interpretation of a fragment identifier without retrieving a representation do so at their own risk; such interpretations are not authoritative.

3.3.2. Fragment Identifiers and Multiple Representations

Story

Dirk informs Nadia that he would also like her to make her images available in formats other than SVG. For the same resource, Nadia makes available a PNG image as well. Dirk's user agent and Nadia's server negotiate so that the user agent retrieves a suitable representation. Which specification specifies the authoritative interpretation of the "hat" fragment identifier, the PNG specification or the SVG specification?

For a given resource, an agent may have the choice between representation data in more than one data format (through HTTP content negotiation, for example). Since different data formats may define different fragment identifier semantics, it is important to note that by design, the secondary resource identified by a URI with a fragment identifier is expected to be the same across all representations. Thus, if a fragment has defined semantics in any one representation, the fragment is identified for all of them, even though a particular data format may not be able to represent it.

Suppose, for example, that the authority responsible for "http://weather.example.com/oaxaca/map#zicatela" provides representations of the resource identified by http://weather.example.com/oaxaca/map using three image formats: SVG, PNG, and JPEG/JFIF. The SVG specification defines semantics for fragment identifiers while the other specifications do not. It is not considered an error that only one of the data formats specifies semantics for the fragment identifier. Because the Web is a distributed system in which formats and agents are deployed in a non-uniform manner, the architecture allows this sort of discrepancy. This design allows authors to take advantage of new data formats while still ensuring reasonable backward-compatibility for users whose agents do not yet implement them.

On the other hand, it is considered an error if the semantics of the fragment identifiers used in two representations of a secondary resource are inconsistent.

Good practice: Fragment identifier consistency

A resource owner who creates a URI with a fragment identifier and who uses content negotiation to serve multiple representations of the identified resource SHOULD NOT serve representations with inconsistent fragment identifier semantics.

Inconsistent fragment identifier semantics are one potential source of URI ambiguity.

See related TAG issues httpRange-14 and RDFinXHTML-35.

3.4. Authoritative Representation Metadata

Successful communication between two parties using a piece of information relies on shared understanding of the meaning of the information. Arbitrary numbers 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 the authoritative interpretation of representations of the resource.

In our travel scenario, the authority responsible for "weather.example.com" has license to create representations of this resource. Which representation(s) Nadia receives depends on a number of factors, including:

Whether the authority responsible for "weather.example.com" responds to requests at all;
Whether the authority responsible for "weather.example.com" makes available one or more representations for the resource identified by "http://weather.example.com/oaxaca";
Whether Nadia has access privileges to such representations (see the section on linking and access control);
If the authority responsible for "weather.example.com" has provided more than one representation (in different formats such as HTML, PNG, or RDF, or in different languages such as English and Spanish), the resulting representation may depend on negotiation between the user agent and server that occurs as part of the HTTP transaction.
When Nadia made the request. Since the weather in Oaxaca changes, Nadia should expect that representations will change over time.

See TAG issues contentTypeOverride-24 and rdfURIMeaning-39.

3.4.1. Inconsistencies between Metadata and Representation Data

Inconsistencies between the data format of representation data and assigned representation metadata do occur. Examples that have been observed in practice include:

The actual character encoding of a representation is inconsistent with the charset parameter in the representation metadata.
The namespace of the root element of XML representation data is inconsistent with the value of the 'Content-Type' field in HTTP headers.

User agents should detect such inconsistencies but should not resolve them without involving the user.

Principle: Authoritative server metadata

User agents MUST NOT silently ignore authoritative server metadata.

Thus, for example, if the parties responsible for "weather.example.com" mistakenly label the satellite photo of Oaxaca as "image/gif" instead of "image/jpeg", and if Nadia's browser detects a problem, Nadia's browser must not silently ignore the problem and render the JPEG image. Nadia's browser can notify Nadia of the problem or notify Nadia and take corrective action. Of course, user agent designers should not ignore usability issues when handling this type of error; notification may be discreet, and handling may be tuned to meet the user's preferences. See the TAG finding "Client handling of MIME headers" for more in-depth discussion and examples.

Furthermore, server managers can help reduce the risk of error through careful assignment of representation metadata (especially that which applies across representations). The section on media types for XML presents an example of reducing the risk of error by providing no metadata about character encoding when serving XML.

3.5. Safe Interactions

Story

Nadia decides to book a vacation to Oaxaca at "booking.example.com." She enters data into a series of online forms and is ultimately asked for credit card information to purchase the airline tickets. She provides this information in another form. When she presses the "Purchase" button, her browser opens another network connection to the server at "booking.example.com" and sends a message composed of form data using the POST method. Note that this is not a safe interaction; Nadia wishes to change the state of the system by exchanging money for airline tickets.

The server reads the POST request, and after performing the booking transaction returns a message to Nadia's browser that contains a representation of the results of Nadia's request. The representation data is in XHTML so that it can be saved or printed out for Nadia's records. Note that neither the data transmitted with the POST nor the data received in the response necessarily correspond to any resource named by a URI.

Nadia's retrieval of weather information (an example of a read-only query or lookup) qualifies as a "safe" interaction; a safe interaction is one where the agent does not incur any obligation beyond the interaction. An agent may incur an obligation through other means (such as by signing a contract). If an agent does not have an obligation before a safe interaction, it does not have that obligation afterwards.

Other Web interactions resemble orders more than queries. These unsafe interactions may cause a change to the state of a resource and the user may be held responsible for the consequences of these interactions. Unsafe interactions include subscribing to a newsletter, posting to a list, or modifying a database.

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

Principle: Safe retrieval

Agents do not incur obligations by retrieving a representation.

For instance, it is incorrect to publish a link that, when followed, subscribes a user to a mailing list. Remember that search engines may follow such links.

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 TAG finding "URIs, Addressability, and the use of HTTP GET and POST".

3.5.1. Unsafe Interactions and Accountability

Story

Nadia pays for her airline tickets online (through a POST interaction as described above). She receives a Web page with confirmation information and wishes to bookmark it so that she can refer to it when she calculates her expenses. Although Nadia can print out the results, or save them to a file, she cannot bookmark the results. In fact, neither the POST request, which expresses her commitment to pay, nor the airline company's response, which expresses its acknowledgment and its own commitment, can be referenced by URIs.

It is a breakdown of the Web architecture if agents cannot use URIs to reconstruct a "paper trail" of transactions, i.e., to refer to receipts and other evidence of accepting an obligation. Indeed, each electronic mail message includes a unique message identifier, one reason why email is so useful for managing accountability (since, for example, email can be copied to public archives). On the other hand, HTTP servers and deployed user agents do not generally keep records of POST transactions, making it difficult for all parties to reconstruct a series of transactions.

There are mechanisms in HTTP, not widely deployed, to remedy this situation. HTTP servers can assign a URI to the results of a POST transaction using the "Content-Location" header (described in section 14.14 of [RFC2616]), and allow authorized parties to retrieve a record of the transaction thereafter via this URI (the value of URI persistence is apparent in this case). User agents can provide an interface for managing transactions where the user agent has incurred an obligation on behalf of the user.

3.6. Representation Management

Story

Since Nadia finds the Oaxaca weather site useful, she emails a review to her friend Dirk recommending that he check out 'http://weather.example.com/oaxaca'. Dirk clicks on the link in the email he receives and is surprised to see his browser display a page about auto insurance. Dirk confirms the URI with Nadia, and they both conclude that the resource is unreliable. Although the managers of Oaxaca have chosen the Web as a communication medium, they have lost two customers due to ineffective resource management.

The usefulness of a resource depends on good management by its owner. As is the case with many human interactions, confident interactions with a resource depend on stability and predictability. The value of a URI increases with the predictability of interactions using that URI. Avoiding unnecessary URI aliases is one aspect of proper resource management.

Good practice: Consistent representation

Publishers of a URI SHOULD provide representations of the identified resource consistently and predictably.

This section discusses important aspects of representation management.

3.6.1. Representation availability

The authority responsible for a resource may supply zero or more representations of a resource. The authority is also responsible for accepting or rejecting requests to modify a resource, for example, by configuring a server to accept or reject HTTP PUT data based on Internet Media Type, validity constraints, or other constraints.

Good practice: Available representation

Publishers of a URI SHOULD provide representations of the identified resource.

3.6.2. URI 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 URI persistence. URI persistence is a matter of policy and commitment on the part of authorities servicing URIs. The choice of a particular URI scheme provides no guarantee that those URIs will be persistent or that they will not be persistent.

Since representations are used to communicate resource state, persistence is directly affected by how well representations are served. Service breakdowns include:

Inconsistent representations served. Note the difference between a resource owner changing representations predictably in light of the nature of the resource (the changing weather of Oaxaca) and the owner changing representations arbitrarily.
Improper use of content negotiation, such as serving two images as equivalent through HTTP content negotiation, where one image represents a square and the other a circle.

HTTP [RFC2616] has been designed to help manage URIs. For example, HTTP redirection (using the 3xx response codes) permits servers to tell an agent that further action needs to be taken by the agent in order to fulfill the request (for example, the resource has been assigned a new URI). In addition, content negotiation also promotes consistency, as a site manager is not required to define new URIs when adding support for a new format specification. Protocols that do not support content negotiation (such as FTP) require a new identifier when a new data format is introduced.

For more discussion about URI persistence, see [Cool].

3.6.3. Linking and Access Control

It is reasonable to limit access to a resource (for commercial or security reasons, for example), but it is unreasonable to prohibit others from merely identifying the resource.

As an analogy: The owners of a building might have a policy that the public may only enter the building via the main front door, and only during business hours. People who work in the building and who make 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.

Story

Nadia and Dirk both subscribe to the "weather.example.com" newsletter. Nadia wishes to point out an article of particular interest to Dirk, using a URI. The authority responsible for "weather.example.com" can offer newsletter subscribers such as Nadia and Dirk the benefits of URIs (such as bookmarking and linking) and still limit access to the newsletter to authorized parties.

The Web provides several mechanisms to control access to resources; these mechanisms do not rely on hiding or suppressing URIs for those resources. For more information, see the TAG finding "'Deep Linking' in the World Wide Web".

3.7. Future Directions for Interaction

There remain open questions regarding Web interactions. The TAG expects future versions of this document to address in more detail the relationship between the architecture described herein, Web Services, the Semantic Web, peer-to-peer systems (including Freenet, MLdonkey, and NNTP [RFC977]), instant messaging systems (including [XMPP]), and voice-over-ip (including RTSP [RFC2326]).

4. Data Formats

A data format (including XHTML, CSS, PNG, XLink, RDF/XML, and SMIL animation) specifies the interpretation of representation data. The first data format used on the Web was HTML. Since then, data formats have grown in number. The Web architecture does not constrain which data formats content providers can use. This flexibility is important because there is constant evolution in applications, resulting in new data formats and refinements of existing formats. Although the Web architecture allows for the deployment of new data formats, the creation and deployment of new formats (and agents able to handle them) is expensive. Thus, before inventing a new data format, designers should carefully consider re-using one that is already available.

For a data 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 a data format requires knowledge of its designers' intentions. Below we describe some characteristics of a data format make it easier to integrate into the Web architecture. This document does not address generally beneficial characteristics of a specification such as readability, simplicity, attention to programmer goals, attention to user needs, accessibility, and internationalization. The section on architectural specifications includes references to additional format specification guidelines.

4.1. Binary and Textual Data Formats

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

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 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 agents in those cases where they can be loaded into memory and used with little or no conversion.

Textual formats are usually more portable and interoperable. 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 maintaining software, and allow the direct intervention of humans in the processing chain without recourse to tools more complex than the ubiquitous text editor. Finally, it simplifies the necessary human task of learning about new data formats (the "view source" effect).

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. Therefore, data format specification authors should make a considered choice between binary and textual format design.

Note: Text (i.e., a sequence of characters from a repertoire) is distinct from serving data with a media type beginning with "text/". Although XML-based formats are textual, many such formats are not primarily comprised of phrases in natural language. See the section on media types for XML for issues that arise when "text/" is used in conjunction with an XML-based format.

See TAG issue binaryXML-30.

4.2. Versioning and Extensibility

Extensibility and versioning are strategies to help manage the natural evolution of information on the Web and technologies used to represent that information.

For more information on about versioning strategies and agent behavior in the face of unrecognized extensions, see TAG issue XMLVersioning-41 and "Web Architecture: Extensible Languages" [EXTLANG].

4.2.1. Versioning

There is typically a (long) transition period during which multiple versions of a format, protocol, or agent are simultaneously in use.

Good practice: Version information

Format designers SHOULD provide for version information in language instances.

4.2.2. Versioning and XML Namespace Policy

Story

Nadia and Dirk are designing an XML data format to encode data about the film industry. They provide for extensibility by using XML namespaces and creating a schema that allows the inclusion, in certain places, of elements from any namespace. When they revise their format, Nadia proposes a new optional "lang" attribute on the "film" element. Dirk feels that such a change requires them to assign a new namespace name, which might require changes to deployed software. Nadia explains to Dirk that their choice of extensibility strategy in conjunction with their namespace policy allows certain changes that do not affect conformance of existing content and software, and thus no change to the namespace identifier is required. They chose this policy to help them meet their goals of reducing the cost of change.

Dirk and Nadia have chosen a particular namespace change policy that allows them to avoid changing the namespace name whenever they make changes that do not affect conformance of deployed content and software. They might have chosen a different policy, for example that any new element or attribute has to belong to a namespace other than the original one. Whatever the chosen policy, it should set clear expectations for users of the format.

Good practice: Namespace policy

Format designers SHOULD document change policies for XML namespaces.

As an example of a change policy designed to reflect the variable stability of a namespace, consider the W3C namespace policy for documents on the W3C Recommendation track. The policy sets expectations that the Working Group responsible for the namespace may modify it in any way until a certain point in the process ("Candidate Recommendation") at which point W3C constrains the set possible changes to the namespace in order to promote stable implementations.

Note that since namespace names are URIs, the party (if any) responsible for a namespace URI has the authority to decide the namespace change policy.

4.2.3. Extensibility

Designers can facilitate the transition process by making careful choices about extensibility during the design of a language or protocol specification.

Good practice: Extensibility mechanisms

Language designers SHOULD provide mechanisms that allow any party to create extensions that do not interfere with conformance to the original specification.

Application needs determine the most appropriate extension strategy for a specification. For example, applications designed to operate in closed environments may allow specification authors to define a versioning strategy that would be impractical at the scale of the Web. As part of defining an extensibility mechanism, a specification should set expectations about agent behavior in the face of unrecognized extensions.

Good practice: Unknown extensions

Language designers SHOULD specify agent behavior in the face of unrecognized extensions.

Two strategies have emerged as being particularly useful:

"Must ignore": The agent ignores any content it does not recognize.
"Must understand": The agent treats unrecognized markup as an error condition.

A powerful design approach is for the language to allow either form of extension, but to distinguish explicitly between them in the syntax.

Additional strategies include prompting the user for more input, automatically retrieving data from available links, and falling back to default behavior. More complex strategies are also possible, including mixing strategies. For instance, a language can include mechanisms for overriding standard behavior. Thus, a data format can specify "must ignore" semantics but also allow people to create extensions that override that semantics in light of application needs (for instance, with "must understand" semantics for a particular extension).

Extensibility is not free. Providing hooks for extensibility is one of many requirements to be factored into the costs of language design. Experience suggests that the long term benefits of extensibility generally outweigh the costs.

4.2.4. Composition of Data Formats

Many modern data format specifications include mechanisms for composition. For example:

It is possible to embed text comments in some image formats, such as JPEG/JFIF. Although these comments are embedded in the containing data, they have little or no effect on the display of the image.
There are container formats such as SOAP which fully expect to be composed from multiple namespaces but which provide an overall semantic relationship of message envelope and payload.
RDF allows well-defined mixing of vocabularies, and allows text and XML to be used as a data type values within a statement having clearly defined semantics.

These relationships can be mixed and nested arbitrarily. In principle, a SOAP message can contain a JPEG image that contains an RDF comment which refers to a vocabulary of terms for describing the image.

Note however, that for general XML there is no semantic model that defines the interactions within XML documents with elements and/or attributes from a variety of namespaces. Each application must define how namespaces interact and what effect the namespace of an element has on the element's ancestors, siblings, and descendants.

See TAG issues mixedUIXMLNamespace-33, xmlFunctions-34, and RDFinXHTML-35.

4.3. Separation of Content, Presentation, and Interaction

The Web is a heterogeneous environment where a wide variety of agents provide access to content to users with a wide variety of capabilities. It is good practice for authors to create content that can reach the widest possible audience, including users with graphical desktop computers, hand-held devices and cell phones, users with disabilities who may require speech synthesizers, and devices not yet imagined. Furthermore, authors cannot predict in some cases how an agent will display or process their content. Experience shows that the allowing authors to separate content, presentation, and interaction concerns promotes reuse and device-independence (see [DIPRINCIPLES]); this follows from the principle of orthogonal of specifications.

Good practice: Separation of content, presentation, interaction

Language designers SHOULD design formats that allow authors to separate content from presentation and interaction concerns.

Note that when content, presentation, and interaction are separated by design, agents need to recombine them. There is a recombination spectrum, with "client does all" at one end and "server does all" at the other. There are advantages to each: recombination on the server allows the server to send out generally smaller amounts of data that can be tailored to specific devices (such as mobile phones). However, such data will not be readily reusable by other clients and may not allow client-side agents to perform useful tasks unanticipated by the author. When a client does the work of recombination, content is likely to be more reusable by a broader audience and more robust. However, such data may be of greater size and may require more computation by the client.

Of course, it may not always be desirable to reach the widest possible audience. Application context may require a very specific display (for a legally-binding transaction, for example). Also, digital signature technology, access control, and other technologies are appropriate for controlling access to content.

Some data formats are designed to describe presentation (including SVG and XSL Formatting Objects). Data formats such as these demonstrate that one can only separate content from presentation (or interaction) so far; at some point it becomes necessary to talk about presentation. Per the principle of orthogonal specifications, these data formats should only address presentation issues.

See the TAG issues formattingProperties-19 and contentPresentation-26.

4.4. Hypertext

A defining characteristic of the Web is that it allows embedded references to other Web resources via URIs. The simplicity of creating links using absolute URIs (<a href="http://www.example.com/foo">) and relative URI references (<a href="foo"> and <a href="foo#anchor">) is partly (perhaps largely) responsible for the birth of the hypertext Web as we know it today.

When one resource (representation) refers to another resource with a URI, this constitutes a link between the two resources. Additional metadata may also form part of the link (see [XLink10], for example).

Good practice: Link mechanisms

Language designers SHOULD provide mechanisms for identifying links to other resources and to portions of representation data (via fragment identifiers).

Good practice: Web linking

Language designers SHOULD provide mechanisms that allow Web-wide linking, not just internal document linking.

Good practice: Generic URIs

Language designers SHOULD allow authors to use URIs without constraining them to a limited set of URI schemes.

What agents do with a hypertext link is not constrained by Web architecture and may depend on application context. Users of the hypertext links expect to be able to navigate links among representations. Data formats that do not allow authors to create hypertext links lead to the creation of "terminal nodes" on the Web.

Good practice: Hypertext links

Language designers SHOULD incorporate hypertext links into a data format if hypertext is the expected user interface paradigm.

4.4.1. URI References

Links are commonly expressed using URI references (defined in section 4.2 of [URI]), which may be combined with a base URI to yield a usable URI. Section 5.1 of [URI] explains different mechanisms for establishing a base URI for a resource and establishes a precedence among the various mechanisms. For instance, the base URI may be a URI for the resource, or specified in a representation (see the base elements provided by HTML and XML, and the HTTP 'Content-Location' header). See also the section on links in XML.

Agents resolve a URI reference before using the resulting URI to interact with another agent. URI references help in content management by allowing authors to design a representation locally, i.e., without concern for which global identifier may later be used to refer to the associated resource.

4.5. XML-Based Data Formats

Many data formats are XML-based, that is to say they conform to the syntax rules defined in the XML specification [XML10]. This section discusses issues that are specific to such formats. Anyone seeking guidance in this area is urged to consult the "Guidelines For the Use of XML in IETF Protocols" [IETFXML], which contains a 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 [IETFXML]. Refer also to "XML Accessibility Guidelines" [XAG] for help designing XML formats that lower barriers to Web accessibility for people with disabilities.

4.5.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 a chosen sequence. It is widely, but not universally, applicable for data format specifications; an audio or video format, for example, is unlikely to be well suited to expression in XML. Design constraints that would suggest the use of XML include:

Requirement for a hierarchical structure.
The data's usefulness should outlive the tools currently used to process it (though obviously XML can be used for short-term needs as well).
Ability to support internationalization in a self-describing way that makes confusion over coding options unlikely.
Early detection of encoding errors with no requirement to "work around" such errors.
A high proportion of human-readable textual content.
Potential composition of the data format with other XML-encoded formats.

4.5.2. Links in XML

Sophisticated linking mechanisms have been invented for XML formats. XPointer allows links to address content that does not have an explicit, named anchor. XLink is an appropriate specification for representing links in hypertext XML applications. XLink allows links to have multiple ends and to be expressed either inline or in "link bases" stored external to any or all of the resources identified by the links it contains.

Designers of XML-based formats should consider using XLink and, for defining fragment identifier syntax, using the XPointer framework and XPointer element() Schemes.

See TAG issue xlinkScope-23.

4.5.3. XML Namespaces

Story

The authority responsible for "weather.example.com" realizes that it can provide more interesting representations by creating instances that consist of elements defined in different XML-based formats, such as XHTML, SVG, and MathML.

How do the application designers ensure that there are no naming conflicts when they combine elements from different formats (for example, suppose that the "p" element is defined in two or more XML formats)? "Namespaces in XML" [XMLNS] provides a mechanism for establishing a globally unique name that can be understood in any context.

Language specification designers that declare namespaces thus provide a global context for instances of the data format. Establishing this global context allows those instances (and portions thereof) to be re-used and combined in novel ways not yet imagined. Failure to provide a namespace makes such re-use more difficult, perhaps impractical in some cases.

Good practice: Namespace adoption

Language designers who create new XML vocabularies SHOULD place all element names and global attribute names in a namespace.

Attributes are always scoped by the element on which they appear. An attribute that is "global," that is, one that might meaningfully appear on different elements, including elements in other namespaces, should be explicitly placed in a namespace. Local attributes, ones associated with only a particular element, need not be included in a namespace since their meaning will always be clear from the context provided by that element.

The type attribute from W3C XML Schema is an example of a global attribute. It can be used by authors of any vocabulary to make an assertion about the type of the element on which it appears. The type attribute occurs in the W3C XML Schema namespace and must always be fully qualified. The frame attribute on an HTML table is an example of a local attribute. There is no value in placing that attribute in a namespace since the attribute is unlikely to be useful on an element other than an HTML table.

Applications that rely on DTD processing must impose additional constraints on the use of namespaces. DTDs perform validation based on the lexical form of the element and attribute names in the document. This makes prefixes syntactically significant in ways that are not anticipated by [XMLNS].

4.5.4. Namespace Documents

Story

Nadia receives a representation data from "weather.example.com" in an unfamiliar data format. She knows enough about XML to recognize which XML namespace the elements belong to. Since the namespace is identified by the URI "http://weather.example.com/2003/format", she asks her browser to retrieve a representation of the namespace via that URI. Nadia is requesting the namespace document.

Nadia gets back some useful data that allows her to learn more about the data format. Nadia's browser may also be able to perform some operations automatically (i.e., unattended by a human overseer) given data that has been optimized for software agents. For example, her browser might, on Nadia's behalf, download additional agents to process and render the format.

There are many reasons to provide information about a namespace. A person might want to:

understand its purpose,
learn how to use the markup vocabulary in the namespace,
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 processor might want to:

retrieve a schema, for validation,
retrieve a style sheet, for presentation, or
retrieve ontologies, for making inferences.

In general, there is no established best practice for creating a namespace document. Application expectations will influence what data format or formats are used to create a namespace document. Application expectations will also influence whether relevant information appears in the namespace document itself or is referenced from it.

Good practice: Namespace documents

Resource owners who publish an XML namespace name SHOULD make available material intended for people to read and material optimized for software agents in order to meet the needs of those who will use the namespace vocabulary.

For example, the following are examples of formats used to create namespace documents: [OWL10], [RDDL], [XMLSCHEMA], and [XHTML11]. Each of these formats meets different requirements described above for satisfying the needs of an agent that wants more information about the namespace. Note, however, issues related to fragment identifiers and multiple representations if content negotiation is used with namespace documents.

See TAG issues namespaceDocument-8 and abstractComponentRefs-37.

4.5.5. QNames in XML

Section 3 of "Namespaces in XML" [XMLNS] provides a syntactic construct known as a QName for the compact expression of qualified names in XML documents. A qualified name is a pair consisting of a URI, which names a namespace, and a local name placed within that namespace. "Namespaces in XML" provides for the use of QNames as names for XML elements and attributes.

Other specifications, starting with [XSLT10], have employed the idea of using QNames in contexts other than element and attribute names, for example in attribute values and in element content. However, general XML processors cannot recognize QNames as such when they are used in attribute values and in element content; they are indistinguishable from URIs. Experience has also revealed other limitations to QNames, such as losing namespace bindings after XML canonicalization.

Good practice: QNames Indistinguishable from URIs

Specifications that use QNames to represent URI/local-name pairs SHOULD NOT allow both forms in attribute values or element content where they would be indistinguishable from URIs.

For more information, see the TAG finding "Using QNames as Identifiers in Content".

Because QNames are compact, some specifications have adopted the same syntax as a means of identifying Web resources. Though convenient as a shorthand notation, this usage has a cost. There is no single, accepted way to convert a QName into a URI or vice-versa. Although QNames are convenient, they do not replace the URI as the identification mechanism of the Web. The use of QNames to identify Web resources without providing a mapping to URIs is inconsistent with Web architecture.

Good practice: QName Mapping

Language designers who use QNames as identifiers of Web resources MUST provide a mapping to URIs.

For examples of QName-to-URI mappings, see [RDF10]. See also TAG issues rdfmsQnameUriMapping-6, qnameAsId-18, and abstractComponentRefs-37.

4.5.6. XML ID Semantics

Consider the following fragment of XML: <section name="foo">. Does the section element have the ID "foo"? One cannot answer this question by examining the element and its attributes alone. In XML, the quality of "being an ID" is associated with the type of the attribute, not its name. Finding the IDs in a document requires additional processing.

Processing the document with a processor that recognizes DTD attribute list declarations (in the external or internal subset) might reveal a declaration that identifies the name attribute as an ID. Note: This processing is not necessarily part of validation. A non-validating, DTD-aware processor can perform ID assignment.
Processing the document with a W3C XML Schema might reveal an element declaration that identifies the name attribute as an xs:ID.
In practice, processing the document with another schema language, such as RELAX NG [RELAXNG], might reveal the attributes of type ID. Many modern specifications begin processing XML at the Infoset [INFOSET] level and do not specify normatively how an Infoset is constructed. For those specifications, any process that establishes the ID type in the Infoset (and Post Schema Validation Infoset (PSVI) defined in [XMLSCHEMA]) may usefully identify the attributes of type ID.

To further complicate matters, DTDs establish the ID type in the Infoset whereas W3C XML Schema produces a PSVI but does not modify the original Infoset. This leaves open the possibility that a processor might only look in the Infoset and consequently would fail to recognize schema-assigned IDs.

See TAG issue xmlIDSemantics-32.

4.5.7. Media Types for XML

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

These Internet Media Types create two problems: First, for data identified as "text/*", Web intermediaries are allowed to "transcode", i.e., convert one character encoding to another. Transcoding may make the self-description false or may cause the document to be not well-formed.

Good practice: XML and "text/*"

In general, server managers SHOULD NOT assign Internet Media Types beginning with "text/" to XML representations.

Second, representations whose Internet Media Types begin with "text/" are required, unless the charset parameter is specified, to be considered to be encoded in US-ASCII. Since the syntax of XML is designed to make documents 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/" Internet Media Types effectively precludes this good practice.

Good practice: XML and character encodings

In general, server managers SHOULD NOT specify the character encoding for XML data in protocol headers since the data is self-describing.

4.5.8. Fragment Identifiers in XML

The section on media types and fragment identifier semantics discusses the interpretation of fragment identifiers. Designers of an XML-based data format specification should define the semantics of fragment identifiers in that format. The XPointer Framework [XPTRFR] provides a interoperable starting point.

When the media type assigned to representation data is "application/xml", there are no semantics defined for fragment identifiers, and authors should not make use of fragment identifiers in such data. The same is true if the assigned media type has the suffix "+xml" (defined in "XML Media Types" [RFC3023]), and the data format specification does not specify fragment identifier semantics. In short, just knowing that content is XML does not provide information about fragment identifier semantics.

Many people assume that the fragment identifier #abc, when referring to XML data, identifies the element in the document with the ID "abc". However, there is no normative support for this assumption.

See TAG issue fragmentInXML-28.

5. Term Index

Dereference a URI: Access the resource identified by the URI.
Fragment identifier: The part of a URI that allows identification of a secondary resource.
Language extension: One language is an extension of a second language if the second is a language subset of the first.
Language subset: One language is a subset of a second language if any document in the first language is also a valid document in the second language and has the same interpretation in the second language.
Link: A relationship between two resources when one resource (representation) refers to the other resource by means of a URI.
Message: A unit of communication between agents.
Namespace document: The resource identified by a namespace URI.
Representation: An octet sequence that consists of representation data and representation metadata, especially a media type.
Representation data: Electronic data expressing resource state, part of a representation of the resource.
Representation metadata: The metadata part of a representation.
Resource: An item of interest in the information space known as the World Wide Web.
Safe interaction: Interaction with a resource where an agent does not incur any obligation beyond the interaction.
Secondary resource: A resource that is related to another resource by a relationship that between representation data, a fragment identifier, and a media type for interpreting the data.
URI ambiguity: The use of the same URI to refer to more than one distinct resource.
URI ownership: The relationship between assigning agent and URI that is defined by a URI scheme.
URI persistence: The social expectation that once a URI identifies a particular resource, it should continue indefinitely to refer to that resource.
URI reference: An operational shorthand for a URI.
Uniform Resource Identifier (URI): A global identifier in the context of the World Wide Web.
Unsafe interaction: Interaction with a resource that is not safe interaction.
User agent: One type of Web agent; a piece of software acting on behalf of a person.
Web agent: A person or a piece of software acting on the information space on behalf of a person, entity, or process.
XML-based format: One that conforms to the syntax rules defined in the XML specification.

6. References

6.1. Internet Specifications

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.
MEDIATYPEREG: IANA's online registry of Internet Media Types is available at http://www.iana.org/assignments/media-types/index.html.
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.
URI: Uniform Resource Identifiers (URI): Generic Syntax (T. Berners-Lee, R. Fielding, L. Masinter, Eds.) is currently being revised. Citations labeled [URI] refer to draft-fielding-uri-rfc2396bis-03.
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. Architectural Specifications

ATAG10: Authoring Tool Accessibility Guidelines 1.0 , J. Treviranus, C. McCathieNevile, I. Jacobs, J. Richards, Editors, W3C Recommendation, 3 February 2000, http://www.w3.org/TR/2000/REC-ATAG10-20000203 . Latest version available at http://www.w3.org/TR/ATAG10 .
CHARMOD: Character Model for the World Wide Web 1.0 , T. Texin, M. J. Dürst, F. Yergeau, R. Ishida, M. Wolf, Editors, W3C Working Draft (work in progress), 22 August 2003, http://www.w3.org/TR/2003/WD-charmod-20030822/ . Latest version available at http://www.w3.org/TR/charmod/ .
DIPRINCIPLES: Device Independence Principles , R. Gimson, Editors, W3C Working Group Note, 1 September 2003, http://www.w3.org/TR/2003/NOTE-di-princ-20030901/ . Latest version available at http://www.w3.org/TR/di-princ/ .
QA: QA Framework: Specification Guidelines , D. Hazaël-Massieux, L. Henderson, L. Rosenthal, Editors, W3C Candidate Recommendation (work in progress), 10 November 2003, http://www.w3.org/TR/2003/CR-qaframe-spec-20031110/ . Latest version available at http://www.w3.org/TR/qaframe-spec/ .
UAAG10: User Agent Accessibility Guidelines 1.0 , I. Jacobs, J. Gunderson, E. Hansen, Editors, W3C Recommendation, 17 December 2002, http://www.w3.org/TR/2002/REC-UAAG10-20021217/ . Latest version available at http://www.w3.org/TR/UAAG10/ .
WCAG20: Web Content Accessibility Guidelines 2.0 , W. Chisholm, G. Vanderheiden, J. White, B. Caldwell, Editors, W3C Working Draft (work in progress), 24 June 2003, http://www.w3.org/TR/2003/WD-WCAG20-20030624/ . Latest version available at http://www.w3.org/TR/WCAG20/ .
WSA: Web Services Architecture , M. Champion, C. Ferris, D. Orchard, D. Booth, H. Haas, F. McCabe, E. Newcomer, Editors, W3C Working Draft (work in progress), 8 August 2003, http://www.w3.org/TR/2003/WD-ws-arch-20030808/ . Latest version available at http://www.w3.org/TR/ws-arch/ .
XAG: XML Accessibility Guidelines , D. Dardailler, S. B. Palmer, C. McCathieNevile, Editors, W3C Working Draft (work in progress), 3 October 2002, http://www.w3.org/TR/2002/WD-xag-20021003 . Latest version available at http://www.w3.org/TR/xag .

EXTLANG: Web Architecture: Extensible Languages, T. Berners-Lee, D. Connolly, 10 February 1998. This W3C Note is available at http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210.
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.
RFC1958: IETF RFC 1958: Architectural Principles of the Internet, B. Carpenter, June 1996. Available at http://www.ietf.org/rfc/rfc1958.txt.

6.3. Additional References

INFOSET: XML Information Set , J. Cowan, R. Tobin, Editors, W3C Recommendation, 24 October 2001, http://www.w3.org/TR/2001/REC-xml-infoset-20011024/ . Latest version available at http://www.w3.org/TR/xml-infoset .
OWL10: OWL Web Ontology Language Reference , M. Dean, G. Schreiber, Editors, W3C Candidate Recommendation (work in progress), 18 August 2003, http://www.w3.org/TR/2003/CR-owl-ref-20030818/ . Latest version available at http://www.w3.org/TR/owl-ref/ .
P3P10: The Platform for Privacy Preferences 1.0 (P3P1.0) Specification , M. Marchiori, Editors, W3C Recommendation, 16 April 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/ . Latest version available at http://www.w3.org/TR/P3P/ .
RDF10: Resource Description Framework (RDF) Model and Syntax Specification , O. Lassila, R. R. Swick, Editors, W3C Recommendation, 22 February 1999, http://www.w3.org/TR/1999/REC-rdf-syntax-19990222 . Latest version available at http://www.w3.org/TR/REC-rdf-syntax .
SOAP12: SOAP Version 1.2 Part 1: Messaging Framework , M. Hadley, N. Mendelsohn, J. Moreau, H. Frystyk Nielsen, M. Gudgin, Editors, W3C Recommendation, 24 June 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ . Latest version available at http://www.w3.org/TR/soap12-part1/ .
SVG11: Scalable Vector Graphics (SVG) 1.1 Specification , J. Ferraiolo, 藤. , D. Jackson, Editors, W3C Recommendation, 14 January 2003, http://www.w3.org/TR/2003/REC-SVG11-20030114/ . Latest version available at http://www.w3.org/TR/SVG11/ .
XHTML11: XHTML™ 1.1 - Module-based XHTML , M. Altheim, S. McCarron, Editors, W3C Recommendation, 31 May 2001, http://www.w3.org/TR/2001/REC-xhtml11-20010531 . Latest version available at http://www.w3.org/TR/xhtml11/ .
XMLSCHEMA: XML Schema Part 1: Structures , H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn, Editors, W3C Recommendation, 2 May 2001, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ . Latest version available at http://www.w3.org/TR/xmlschema-1/ .
XLink10: XML Linking Language (XLink) Version 1.0 , S. J. DeRose, E. Maler, D. Orchard, Editors, W3C Recommendation, 27 June 2001, http://www.w3.org/TR/2001/REC-xlink-20010627/ . Latest version available at http://www.w3.org/TR/xlink/ .
XML10: Extensible Markup Language (XML) 1.0 (Second Edition) , T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, Editors, W3C Recommendation, 6 October 2000, http://www.w3.org/TR/2000/REC-xml-20001006 . Latest version available at http://www.w3.org/TR/REC-xml .
XMLNS: Namespaces in XML , T. Bray, D. Hollander, A. Layman, Editors, W3C Recommendation, 14 January 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114 . Latest version available at http://www.w3.org/TR/REC-xml-names .
XPTRFR: XPointer Framework , P. Grosso, E. Maler, J. Marsh, N. Walsh, Editors, W3C Recommendation, 25 March 2003, http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ . Latest version available at http://www.w3.org/TR/xptr-framework/ .
XSLT10: XSL Transformations (XSLT) Version 1.0 , J. Clark, Editors, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/1999/REC-xslt-19991116 . Latest version available at http://www.w3.org/TR/xslt .

CGI: Common Gateway Interface/1.1 Specification. Available at http://hoohoo.ncsa.uiuc.edu/cgi/interface.html.
Cool: Cool URIs don't change T. Berners-Lee, W3C, 1998 Available at http://www.w3.org/Provider/Style/URI. Note that the title is somewhat misleading. It is not the URIs that change, it is what they identify.
Eng90: Knowledge-Domain Interoperability and an Open Hyperdocument System, D. C. Engelbart, June 1990.
FREENET: The Free Network Project.; Dan Connolly's list of URI schemes is a useful resource for finding out which references define various URI schemes.
IETFXML: 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.
IRI: 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)'.
MLDONKEY: The MLDonkey Project
RDDL: Resource Directory Description Language (RDDL), J. Borden, T. Bray, eds., 1 June 2003. This document is available at http://www.tbray.org/tag/rddl/rddl3.html.
RELAXNG: The RELAX NG schema language project.
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. Available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.
RFC977: IETF RFC 977: Network News Transfer Protocol, B. Kantor, P. Lapsley, February 1986. Available at http://www.ietf.org/rfc/rfc977.txt.
RFC2141: IETF RFC 2141: URN Syntax, R. Moats, May 1997. Available at http://www.ietf.org/rfc/rfc2141.txt.
RFC2326: IETF RFC 2326: Real Time Streaming Protocol (RTSP), H. Schulzrinne, A. Rao, R. Lanphier, April 1998. Available at: http://www.ietf.org/rfc/rfc2326.txt.
RFC2718: IETF RFC 2718: Guidelines for new URL Schemes, L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, November 1999. Available at: http://www.ietf.org/rfc/rfc2718.txt.
RFC2818: IETF RFC 2818: HTTP Over TLS, E. Rescorla, May 2000. Available at: http://www.ietf.org/rfc/rfc2818.txt.
RFC3023: 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
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
UNICODE: See the Unicode Consortium home page for information about the latest version of Unicode and character repertoires.
UniqueDNS: IAB Technical Comment on the Unique DNS Root, B. Carpenter, 27 September 1999. Available at http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm.
XMPP: The Extensible Messaging and Presence Protocol (XMPP) IETF Working Group is developing "an open, XML-based protocol for near real-time extensible messaging and presence. It is the core protocol of the Jabber Instant Messaging and Presence technology..."

Architecture of the World Wide Web, First Edition

Editor's Draft 5 December 2003

Abstract

Status of this document

Table of Contents

List of Principles and Good Practice Notes

1. Introduction

1.1. About this Document

1.1.1. Audience of this Document

1.1.2. Scope of this Document

1.1.3. Principles, Constraints, and Good Practice

1.2. General Architecture Principles

1.2.1. Orthogonal Specifications

1.2.2. Extensibility

1.2.3. Error Handling

1.2.4. Protocol-based Interoperability

2. Identification

2.1. URI Comparisons

2.2. URI Ownership

2.3. URI Ambiguity

2.3.1. URIs in other Roles

2.4. URI Schemes

2.4.1. URI Scheme Registration

2.5. URI Opacity

2.6. Fragment Identifiers

2.7. Future Directions for Identifiers

2.7.1. Internationalized Identifiers

2.7.2. Assertion that Two URIs Identify the Same Resource

3. Interaction

3.1. Using a URI to Access a Resource

3.2. Messages and Representations

3.3. Internet Media Type

3.3.1. Media Types and Fragment Identifier Semantics

3.3.2. Fragment Identifiers and Multiple Representations

3.4. Authoritative Representation Metadata

3.4.1. Inconsistencies between Metadata and Representation Data

3.5. Safe Interactions

3.5.1. Unsafe Interactions and Accountability

3.6. Representation Management

3.6.1. Representation availability

3.6.2. URI Persistence

3.6.3. Linking and Access Control

3.7. Future Directions for Interaction

4. Data Formats

4.1. Binary and Textual Data Formats

4.2. Versioning and Extensibility

4.2.1. Versioning

4.2.2. Versioning and XML Namespace Policy

4.2.3. Extensibility

4.2.4. Composition of Data Formats

4.3. Separation of Content, Presentation, and Interaction

4.4. Hypertext

4.4.1. URI References

4.5. XML-Based Data Formats

4.5.1. When to Use an XML-Based Format

4.5.2. Links in XML

4.5.3. XML Namespaces

4.5.4. Namespace Documents

4.5.5. QNames in XML

4.5.6. XML ID Semantics

4.5.7. Media Types for XML

4.5.8. Fragment Identifiers in XML

5. Term Index

6. References

6.1. Internet Specifications

6.2. Architectural Specifications

6.3. Additional References

7. Acknowledgments