Architecture of the World Wide Web

Editor's Draft 27 October 2003

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


The World Wide Web is an network-spanning information space consisting of resources, which are interconnected by links defined within that space. This information space is the basis of, and is shared by, a number of information systems. Within each of these systems, agents (e.g., browsers, servers, spiders, and proxies) provide, retrieve, create, analyze, and reason about resources.

Web architecture encompasses both the definition of the information space in terms of identification and representation of its contents, and the protocols that define the interaction of agents within an information system making use of the space. Web architecture is influenced by social requirements and software engineering principles, leading to design choices that constrain the behavior of systems using the Web in order to achieve desired properties of the shared information space: efficiency, scalability, and the potential for indefinite growth across languages, cultures, and media. This document reflects the three dimensions of Web architecture: identification, interaction, and representation.

Editor's note: The TAG expects to rewrite the abstract in light of other changes to the document.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document has been developed by W3C's Technical Architecture Group (TAG) (charter). Please send comments on this document to the public W3C TAG mailing list www-tag@w3.org (archive).

This draft incorporates significant discussion from the TAG's face-to-face meeting in Bristol, in early October 2003. A complete list of changes since the previous Working Draft is available on the Web. This draft includes some editorial notes and also references to open TAG issues. These do not represent all open issues in the document. They are expected to disappear from future drafts.

The TAG has published a number of findings that address specific architecture issues. Parts of those findings may appear in subsequent drafts.

This document is intended to inform discussions about issues of Web architecture. Where current practice conflicts with it, this document and related findings are intended to help the relevant parties address these issues. Some parts of this document may fill in gaps in published specifications or may call attention to known weaknesses in those specifications.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than "work in progress." The latest information regarding patent disclosures related to this document is available on the Web.

Table of Contents

List of Principles and Good Practice Notes

The following principles and good practice notes explained in this document are listed here for convenience.

General Architecture Principles
  1. Identify features that cross abstraction levels
  2. Error recovery
  3. Specify error handling
  4. Scope of Design Constraints
  1. URI uniqueness
  2. Use URIs
  3. Thoughtful URI creation
  4. Use URIs consistently
  5. URI ambiguity
  6. New URI schemes
  7. URI Opacity
  1. Fragment identifier consistency:
  2. Authoritative server metadata
  3. Don't guess metadata
  4. Safe retrieval
  5. Consistent representations
  6. Available representations
  1. Format specification availability
  2. Media type registration
  3. Specified fragment identifier semantics
  4. Binary or text
  5. Format extensibility
  6. Format compatibility
  7. Compatibility behavior
  8. Content, Presentation, Interaction Separation
  9. Link mechanisms
  10. Web linking
  11. Generic URIs
  12. Use of Hyperlinks
  13. Use Namespaces
  14. QName Mapping
  15. QNames Indistinguishable from URIs
  16. Namespace documents
  17. XML and text/*

1. Introduction

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

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


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:

  1. The browser performs an information retrieval action in accordance with its configured behavior for resources identified via the "http" URI scheme.
  2. The authority responsible for "weather.example.com" responds to the retrieval action, providing information in a response.
  3. The browser displays the retrieved information, which includes links to other information via additional URI references. Nadia can follow these links to initiate new retrieval request actions.

This scenario (elaborated on throughout the document) illustrates the three architectural dimensions of the Web that are discussed in this document:

  1. Identification. Each resource is identified by a Uniform Resource Identifier (URI). In this travel scenario, the resource involves the weather in Oaxaca and the URI is "http://weather.example.com/oaxaca".
  2. Interaction. Protocols define the syntax and semantics of messages exchanged by agents over a network about Web resources. Web agents communicate complete or partial information about the state of a resource through representations. In the travel scenario, Nadia (by clicking on a link) tells her browser to request a representation of the resource identified by the URI in the 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".
  3. 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, which includes links to several SVG weather map images. While interpreting the XHTML representation data, which includes references to weather maps identified by URIs; the browser retrieves and displays those maps.

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

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

Editor's note: The TAG may include additional illustrations in this document to help explain important terms and their relationships.

1.1. About this Document

This document is an ongoing attempt to describe the properties we desire of the Web and the design choices that have been made to achieve them.

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.

1.1.1. Audience of this Document

The intended audience for this document includes:

  1. Participants in W3C Activities; i.e., developers of Web technologies and specifications in W3C
  2. Other groups and individuals developing technologies to be integrated into the Web
  3. Implementers of W3C specifications
  4. 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 focuses on the 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 strives for brevity and precision while including illustrative examples. TAG findings provide more background, motivation, and examples. The findings do not contain good practice notes, principles, etc. beyond those that appear in the current document.

The architecture described in this document is primarily the result of experience. There has been theoretical and modeling work in the area of Web architecture, notably 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 dimensions of Web architecture.

1.2.1. Orthogonal Specifications

Identification, interaction, and representation are orthogonal 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 is an important principle in Web architecture. It 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.

Specifications should identify orthogonal abstractions. For example, the header and body of a message are, to a large extent, orthogonal concepts. It is valuable that HTML and SOAP have both identified the concepts of header and body.

Orthogonal abstractions deserve orthogonal specifications. When it is necessary for a specification to define a feature that simultaneously accesses information from otherwise orthogonal abstractions, for example a feature that requires information from both the header and the body of a message or a feature that needs to infer information about the representations of a URI that are available, the fact that it is "peeking" across architectural boundaries should be clearly identified.

Good practice: Identify features that cross abstraction levels

Format specification authors SHOULD clearly identify the features of a specification that cross abstraction levels.

1.2.2. Error Handling

Errors occur in the deployment of software and data. The degree to which errors are tolerated varies depends on application context. User agents act on behalf of the user and therefore are 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 observation about error-handling approaches.

  • Protocol designers should provide enough information about the error condition so that a person or agent can address the error condition. For instance, an HTTP 404 message ("resource not found") is useful because it allows agents to present information to users that enables them to contact the author of the representation that included the (broken) link. Similarly, 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 "halt-and-catch-fire" upon encountering ill-formed content. Because users are unlikely to tolerate agents that halt-and-catch-fire, this design choice has pressured all parties into respecting XML's constraints, to the benefit of all.
  • There are costs and benefits when an agent ignores unrecognized content. The common practice by HTML user agents of ignoring unknown elements contributed to the growth of the Web by allowing the rapid deployment of new ideas. However, this behavior also contributed to interoperability problems among early browsers. See the section on extensibility and versioning for related information.
  • Error behavior that is sufficient for a person may not be sufficient for a processor. 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.

Good practice: Specify error handling

Specification authors SHOULD specify agent behavior in the face of error conditions.

See the TAG finding "Client handling of MIME headers" for more discussion about error reporting. See also TAG issue errorHandling-20.

1.2.3. Web as a Distributed System

The Web is a highly distributed system. Software developers, content developers, and specification designers need to be aware that what may hold in their "neighborhood" may not hold at the scope of the entire Internet. Some examples include:

  • Internationalization issues such as whether a user is a fluent English speaker.
  • User agent behavior. Not all user agents behave the same way, and all users do not share the same capabilities. Someone with a cell phone may wish to view your Web content on a very small screen. Users with blindness or a physical disability may not use a mouse.
  • Error behavior. Since the Web is a distributed system, protocol designers should not constrain agents in different parts of the network to remain synchronized.
  • URI space. The authority to create URIs should not be constrained by arbitrary specifications. The "robots.txt" file discussed in the HTML specification is an example of a specification attempting to limit inappropriately the set of URIs a resource owner may create. See TAG issue siteData-36 for more information.
  • URI scope. URIs have a global scope. The resource identified by a URI does not depend on the context in which the URI appears. Of course, what an agent does with a URI may vary.

Good practice: Scope of Design Constraints

Software developers, content developers, and specification authors SHOULD NOT impose constraints that suppose that the Web is a closed system.

1.2.4. Syntax and Interoperability

Editor's note: This section is new and very much in flux.

The general success of Web software is evidence that interoperability in networked information systems is best achieved when interfaces specified at the level of concrete syntax are available as the default mode of interaction. Concrete syntax provides a basis for interoperability in networked information systems such as the Web.

2. Identification

Parties who wish to communicate about something agree upon a shared set of identifiers and on their meanings. This shared vocabulary has a tangible value: it reduces the cost of communication. The ability to use common identifiers across communities motivates global identifiers in Web architecture. Thus, Uniform Resource Identifiers [URI], are central to Web architecture.

A URI must be assigned to a resource in order for the resource to be linked within the information space. 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.

Constraint: URI uniqueness

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

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

Principle: Use URIs

A resource owner SHOULD assign a URI to each resource that is intended to be identified, shared, or described by reference.

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

As stated above, Web architecture allows resource owners to assign more than one URI to a resource. This freedom does not imply that URIs that are not identical (character for character) 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: Thoughtful URI creation

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 section 2 of [URI].

Good practice: Use URIs consistently

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 (e.g., for "http" URIs, the authority component is case-insensitive) that are licensed by specifications to reduce the risk of false negatives and positives. Web 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.

Refer to 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 solutions other than string comparison that may allow different parties to determine that two URIs identify the same resource.

2.2. URI Ambiguity

URI ambiguity refers to the use of the same URI to refer to more than one distinct resource. Consider the following scenario: One division of a company maintains data about Web pages, including who created them and when. This division naturally uses the URI of the page to identify it. Another division of the company maintains data about corporations, including who created them and when. They use the URI of the corporation's home page to identify it.

If the two divisions decide to merge their data, they will have to exercise care or the fact that they are using the same URIs to identify two different resources will cause problems.

Ambiguity is an error and should not be confused with indirect identification. Indirect identification occurs when a resource is identified through another resource to which it has a known relationship. For example, people can be identified by their email addresses or organizations by their web pages. When conference organizers ask meeting participants to register by giving their email addresses, both parties know that they are using the mailbox identifier to indirectly identify the person. The URI "mailto:joe@example.com" still identifies the mailbox, not the person.

URI ambiguity should not be confused with ambiguity in natural languages. The natural language statement "'http://www.example.com/moby' identifies 'Moby Dick'" is ambiguous because one could understand the statement to refer to very 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.

URI ambiguity only arises if different parties believe that "http://www.example.com/moby" identifies different things.

Good practice: URI ambiguity

Avoid URI ambiguity.

2.3. URI Schemes

In the URI "http://weather.example.com/", the "http" that appears before the colon (":") is a URI scheme name. 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. Furthermore, the URI scheme specification specifies whether and how an agent can dereference the URI.

Examples of URIs from various schemes include:

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

Since many aspects of URI processing are scheme-dependent, and since a huge amount of deployed software already processes URIs of well-known schemes, the cost of introducing a new URI scheme is high.

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". While the Web architecture allows the definition of new schemes, there is a cost to registration and especially deployment of new schemes. When an agent dereferences such a URI, if what really happens is that HTTP GET is invoked to retrieve an HTML representation of the resource, then an "http" URI would have sufficed. If a URI scheme exists that meets the needs of an application, designers should use it rather than invent one.

If the motivation behind registering a new scheme is to allow an agent to launch a particular application when retrieving a representation, such dispatching can be accomplished at lower expense by registering a new Internet Media Type instead. Deployed software is more likely to handle the introduction of a new media type than the introduction of a new URI scheme.

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

Note: Some URI scheme specifications use the term "designate." This document uses "identify" rather than "designate" in some of the descriptions above.

Editor's note: In a future version of this document, the TAG may summarize some URI schemes and what the scheme specification licenses agents to infer by recognizing the scheme.

2.4. 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. For example, in general, one cannot determine the Internet Media Type of representation of a resource by inspecting a URI for that resource. 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 the PNG or any other 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

Web 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 Web 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, refer to the TAG finding The use of Metadata in URIs.

2.5. Fragment Identifiers


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. More precisely:

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. Note that the presence of a fragment identifier in a URI does not imply that the URI will be dereferenced.

2.6. 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. The TAG makes no commitment at this time to pursuing these issues.

2.6.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.6.2. Determination that Two URIs Identify the Same Resource

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

2.6.3. Work on Dynamic Authority Delegation

The Dynamic Delegation Discovery System (DDDS) ([RFC3401] and related RFCs) is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. This system is designed to allow resolution of any type of URI, in particular URNs.

2.6.4. Non-hierarchical Administration

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

3. Interaction

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


Nadia follows a 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 (e.g., 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.

Editor's note: The TAG has not yet reached agreement about whether to distinguish "information resources" from other types of resources. An information resource is one that conveys information (via representations). See TAG issue httpRange-14. Related to the concept of "information resource" is the expression "on the Web". Roy Fielding suggested this definition of "on the Web": "A resource is considered to be "on the Web" if it can be independently referred to by at least one URI, even if access to that resource is restricted." Others have expressed that actual access should be a requirement as well.

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

There may be more than one way to access a resource for a given URI; context may determine 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 (e.g., the URN scheme [RFC 2141]) do not set expectations themselves about available access mechanisms. 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, refer to 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, and the resolution of some URIs may require the use of more than one protocol (e.g., both DNS and HTTP are typically used to access an "http" URI's origin server when a representation isn't found in a local cache).

Dereferencing a URI generally involves a number of different steps, which may be defined in different format and protocol specifications implemented by the agent. The following example illustrates the series of specifications that are involved when an agent dereferences the URI "http://weather.example.com/oaxaca" that is part of a link in an SVG document.

  1. Since the URI is part of a link in an SVG document, the first relevant specification is the SVG 1.1 Recommendation [SVG11]. This specification imports the link semantics defined in XLink 1.0 [XLink10]. Section 17.1 of the SVG specification suggests that interaction with an a link involves retrieving a representation of a resource, identified by the XLink href attribute: "By activating these links (by clicking with the mouse, through keyboard input, and voice commands), users may visit these resources."
  2. The attribute xlink:href is defined in section 5.4 of the XLink 1.0 [XLink10] specification, which 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."
  3. 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".
  4. To find out what specification defines the "http" scheme, we look up the mapping in [IANASchemes]; the "http" URI scheme is defined in the HTTP/1.1 specification (RFC 2616 [RFC2616], section 3.2.2).
  5. The HTTP/1.1 specification defines several access mechanisms. In this SVG context, the user agent employs the GET method (defined in section 9.3 of [RFC2616]) to retrieve the representation. The HTTP/1.1 specification explains how the server constructs the response (section 6 of [RFC2616]), including the 'Content-Type' field. Section 1.4 states "HTTP communication usually takes place over TCP/IP connections." Though not shown in this example, the user agent would continue this process by implementing those specifications.
  6. The user 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].

Editor's note: Chris Lilley is expected to provide a revised version of the above sequence.

3.2. Messages and Representations

A message is an event that represented in a non-exclusive set of messaging protocols (e.g., HTTP, FTP, NNTP, SMTP, etc.). Messages may carry data, metadata about the data, and message metadata: metadata about the message (e.g., the HTTP Transfer-encoding header). A message may even include metadata about the message metadata (e.g., for message-integrity checks).

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 result messages (e.g., a response to an HTTP GET, but not an HTTP POST) may carry the following information:

  1. A partial or complete representation of the state of the resource is an octet sequence that consists of two parts:
    1. Electronic data about resource state, expressed in one or more formats used separately or in combination, and
    2. An Internet Media Type, which governs the interpretation of the representation data.
    Agents use representations to modify as well as retrieve resource state.
  2. Representation metadata such as the HTTP Content-Type field and HTTP Etags;
  3. Resource metadata, such as the HTTP 'Alternates' and 'Vary' headers.

3.3. Internet Media Type

The Internet Media Type [RFC2046]) governs the authoritative interpretation of representation data. An agent interprets representation data by looking up the Internet Media Type in the IANA registry [MEDIATYPEREG]. Each media type refers to one or more format specifications. If the user agent implements those specifications, it interprets the data accordingly; error handling is discussed below. In this document, the phrase "media type M" is shorthand for "the data format defined by the specification(s) paired with Internet Media Type M in the IANA registry."

3.3.1. Media Types and Fragment Identifier Semantics

The URI specification [URI] states that given a URI with a fragment identifier "U#F":

  • The authoritative interpretation of "F" depends on the format specification of representation data that is part of a representation of the resource identified by "U".

The interpretation of "F" does not depend on the representation where "U#F" appears but on the representation retrieved by dereferencing "U".

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 (e.g., proxies) have no effect on fragment identifiers and that redirection (in HTTP [RFC2616], for example) does not account for them.

3.3.2. Fragment Identifiers and Multiple Representations

At a given moment, for a given resource, an agent may have the choice between representation data in more than one data format (e.g., through HTTP content negotiation). Since different data formats may define different fragment identifier semantics, it is important to note the following:

  1. A secondary resource is represented by the union of all representations of that resource.
  2. If a fragment has defined semantics in any one representation, the fragment is identified for all of them, even though a particular format cannot represent it.

Suppose, for example, that the party responsible for "http://weather.example.com/oaxaca/map#zicatela" provides representations of the identified resource 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 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. Authors may take advantage of more powerful 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 that creates a URI with a fragment identifier and that uses content negotiation to serve multiple representations of the identified resource SHOULD NOT serve representations with inconsistent fragment identifier semantics.

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

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. Large 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. See the TAG finding "Client handling of MIME headers" for related discussion. See also TAG issue rdfURIMeaning-39.

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

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

3.4.1. Inconsistencies between Metadata and Representation Data

Inconsistencies between the 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 the 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 (for example, due to security issues).

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, notify Nadia and take corrective action, etc. 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.

Principle: Don't guess metadata

Server managers MUST ensure that representation metadata is appropriate for each representation.

Editor's note: Add an example of this principle.

3.5. Safe Interactions


Nadia decides to book a vacation to Oaxaca at "booking.example.com." She completes a series of HTML forms and is ultimately asked for credit card information to purchase the airline tickets. She provides this information in another HTML form. When she presses the "Purchase" button, her browser opens another network connection to the server at "booking.example.com" and sends a message conforming to the rules for an HTTP POST request.

As described by the HTML specification, the message data consists of a set of name/value pairs corresponding to the HTML form fields. 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 HTML 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 qualifies as a "safe" interaction; a safe interaction is one where the agent does not commit to anything beyond the interaction and is not responsible for any consequences other than the interaction itself (e.g., a read-only query or lookup). 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 (e.g., 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 (e.g., "http://example.com/oaxaca/newsLetter") 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.6. Representation Management

The health of a resource depends on care and feeding by the resource owner. Thoughtful URI creation is one aspect of proper resource management. The value of a URI increases with the predictability of interactions using that URI.

Good practice: Consistent representations

Publishers of a URI SHOULD provide (or not) 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, e.g., by configuring a server to accept or reject HTTP PUT data based on Internet Media Type, validity constraints, or other constraints.

Good practice: Available representations

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

In terms of user frustration, there is little difference between the inability to retrieve a representation for an important resource due to a network outage and the inability because none has been provided.

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 (e.g., the weather in Oaxaca changes) 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 service URIs. For example, HTTP redirection (via some of the 3xx response codes) permits servers to tell a user agent that further action needs to be taken by the user agent in order to fulfill the request (e.g., the resource has been assigned a new URI). In addition, content negotiation also promotes consistency, as a site manager is not required to define new URIs when adding support for a new format specification. Protocols that do not support content negotiation (e.g., FTP) require a new identifier when a new format is introduced.

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

3.6.3. Access Control

It is reasonable to limit access to the resource (e.g., for security reasons), 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.


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 (e.g., book marking and linking) and still limit access to the newsletter to authorized parties.

The Web provides several mechanisms to control access to resources, none of which relies on hiding or suppressing URIs for those resources. For more information, please refer to the TAG finding "'Deep Linking' in the World Wide Web."

3.7. Future Directions for Interactions

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, and the Semantic Web.

3.8. Moved here from other sections temporarily

4. Formats

Data formats (e.g., XHTML, CSS, PNG, XLink, RDF/XML, and SMIL animation) are used to build representations. Each data format is defined by a format specification. The first data format used on the Web was HTML. Since then, data formats for the Web 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. This evolution results in new data formats and refinements of existing formats.

Some characteristics of a data format make it easier to integrate into the Web architecture. We examine some of those characteristics below. This document does not address generally beneficial characteristics of a specification such as readability, simplicity, attention to programmer goals, attention to user needs, accessibility, internationalization, etc. The section on architectural specifications includes references to additional format specification guidelines.

Note: This document does not distinguish in any significant way the terms "format," "language," and "vocabulary." Context has determined which term is used.

4.1. Interoperability and the Use of Standard Format Specifications

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 electronic data usually requires knowledge of its designers' intentions.

Good practice: Format specification availability

To promote the interoperability of a Web data format, the format authors SHOULD provide a stable, normative specification for it that is a widely available Web resource.

Good practice: Media type registration

Format specification authors SHOULD register an Internet Media Type for each format specification they wish to promote (see the [MEDIATYPEREG] registry).

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

Good practice: Specified fragment identifier semantics

Format specification authors SHOULD define the syntax and semantics of fragment identifiers for the format.

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 very expensive. Thus, before inventing a new data format, designers should carefully consider re-using one that is already available.

4.2. 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, since there are fewer choices for representation of the basic units (characters), and those choices are well-understood and widely implemented.

Textual formats also have the considerable advantage that they can be directly read and understood by human beings. This can simplify the tasks of creating and maintaining processing 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.

Good practice: Binary or text

Format specification authors SHOULD make a considered choice between binary and textual.

Note: Text (i.e., a sequence of characters from a repertoire) is distinct from serving data with a media type of "text/". When data include sentences in natural language, identifying the data as "text/" suggests that it may be useful for people to "view source." 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.

TAG issue binaryXML-30: Effect of Mobile on architecture - size, complexity, memory constraints. Binary Infosets, storage efficiency.

4.3. Extensibility and Versioning

Editor's note: The TAG has begun work on a finding on the topic of extensibility and versioning. The text in this section is likely to change once that finding has been published.

A format is extensible if instances of the format can include terms from other vocabularies. For example, XML and XML Namespaces allow format designers to create and combine vocabularies.

Good practice: Format extensibility

Format specification authors should create extensible formats.

Versioning is the term for the evolution of formats and documents. Versioning is achieved through extensibility mechanisms and format redefinition. When a format definition changes (e.g., by addition or removal of element or attribute definitions), this creates a new version of the format. When an instance of a format includes elements from another data format, this creates an extension of the instance; the original format definition has not changed. An example is a SOAP message with a header block; this is called a SOAP extension, not a new version of the SOAP format.

The following terms define important relationships among different versions of a format:

Compatible formats
Format version M is compatible with format version N if agents designed to process all instances of M can also process all instances of N. The compatibility relationship is not always symmetric.
Forwards compatibility
Format version M is forwards compatible with respect to format version N if M is compatible with N and M predates N.
Backwards compatibility
Format version M is backwards compatible with respect to format version N if M is compatible with N and N predates M.

Good practice: Format compatibility

Format specification authors SHOULD define extensibility models that allow forwards compatible and backwards compatible changes.

Naturally, even if M and N are compatible but different versions of a format, agents will process instances of them differently. For instance, if format version M is forwards compatible with format version N, M processors that encounter N instances might handle unknown elements by ignoring them entirely, or by ignoring element tags but continuing to process element content. Different format specifications may require different compatibility behavior.

Good practice: Compatibility behavior

Format specification authors SHOULD define expected behavior when agents designed to process one version of a format encounter a compatible version of the format.

In some cases, format designers require that new features be supported (i.e., not ignored). In this case, the new version of the format (N) may be backwards compatible with the earlier version (M), but M is not forwards compatible with N. The SOAP 1.2 Recommendation [SOAP12], for example, defines the mustUnderstand attribute in section 5.2.3.

For more information on format extensibility, refer to "Web Architecture: Extensible Languages" [EXTLANG].

4.4. Separation of Presentation, Content, and Interaction

The Web is a heterogeneous environment where a wide variety of user agents provide access to content to users with a wide variety of capabilities. Generally authors need to create content that can reach the widest possible audience, including users with graphical desktop computers, hand-held devices, cell phones, speech synthesizers, and other specialized hardware or software. Furthermore, authors cannot predict how every user agent will display or process their content. Experience shows that the allowing authors to separate content logic from presentation and interaction concerns helps them reach the widest possible audience.

Good practice: Content, Presentation, Interaction Separation

Format specification authors SHOULD design formats that allow authors to separate content logic from presentation and interaction concerns.

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

See the general principle on orthogonal specifications and the TAG issues formattingProperties-19 and contentPresentation-26.

4.5. Web-Enabled Linking

One of the most interesting features of the Web is that it allows authors to embed references to other Web resources via URIs. The simplicity of <a href="#foo"> as a link to foo and <a name="foo"> as the anchor foo are partly (perhaps largely) responsible for the birth of the hypertext Web as we know it today.

When a representation of one resource refers to another resource with a URI, this constitutes a link between the two resources. The networked information space is built of linked resources, and the large-scale effect is a shared information space. The value of the Web grows exponentially as a function of the number of linked resources (the "network effect").

Many formats allow authors to use shortcuts for writing URIs in order to facilitate content management. Strings such as "#anchor" and "../" are familiar examples of what section 4.2 of [URI] calls URI references. Web agents resolve URI references to URIs (according to the algorithm defined in section 5 of [URI]) before using them to interact with other agents.

Good practice: Link mechanisms

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

Good practice: Web linking

Format specification authors SHOULD provide mechanisms that allow Web-wide linking, not just internal document linking.

What agents do with a link is not constrained by Web architecture. Agent behavior depends on application context, which may include additional metadata about the relationship embodied by the link. For instance, agents may consider a link may to be active or passive. Hypertext browsers usually consider anchors and in-line image references to be active links (also called hyperlinks), whereas a reasoning system might focus activity on assertions, a messaging agent might traverse service descriptions, or a subscriber might describe "callback" control-points.

Good practice: Generic URIs

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

Users of the hypertext Web expect to be able to navigate links among representations. Data formats that do not allow authors to create hyperlinks lead to the creation of "terminal nodes" on the Web.

Good practice: Use of Hyperlinks

Format specification authors SHOULD incorporate hypertext links into a format if hypertext is the expected user interface paradigm.

Per the above good practice note, hypertext links should be based on URIs. See also the section on links in XML.

4.6. 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 very thorough discussion of the considerations that govern whether or not XML ought to be used, as well as specific guidelines on how it ought to be used. While it is directed at Internet applications with specific reference to protocols, the discussion is generally applicable to Web scenarios as well.

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

4.6.1. When to Use an XML-Based Format

XML defines textual data formats that are naturally suited to describing data objects which are hierarchical and processed in an in-order sequence. It is widely, but not universally applicable for format specifications; 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:

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

4.6.2. XML Namespaces


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 (e.g., 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.

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

Format 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: Use Namespaces

Format specification authors that 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. In that respect they are a somewhat special case. An attribute that is "global," that is, one that might meaningfully appear on a great many 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 very 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 semantically significant in ways that are not anticipated by [XMLNS]. As other schema technologies become widely deployed, this drawback will diminish in significance.

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

For formats based on XML, format designers should consider using XLink and the XPointer framework. To define fragment identifier syntax, use at least the XPointer Framework and XPointer element() Schemes.

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

If a future revision of RFC 3023 identifies the XPointer Framework, element(), and perhaps other ancillary schemes as the fragment identifier syntax for XML documents, authors will be able to rely on at least those schemes for all XML documents.

Good practice: QName Mapping

Format specification authors who use QNames MUST provide a mapping to URIs.

Good practice: QNames Indistinguishable from URIs

Format specification authors MUST NOT define an attribute whose value may be either a URI or QName since the two types cannot be distinguished by syntax.

Editor's note: The two previous points need more introduction.

See the TAG finding "Using QNames as Identifiers in Content" for more information. See also TAG issues rdfmsQnameUriMapping-6 and qnameAsId-18.

4.6.4. Namespace Documents


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 a URI, 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 use data optimized for agents automatically (i.e., unattended by a human overseer) to perform useful tasks on Nadia's behalf, such as 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 "best" data format for creating a namespace document. Application expectations will influence what 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 identifier SHOULD make available material intended for people to read and material optimized for 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 [XHTML]. Each of these formats meets different requirements described above for satisfying the needs of a person or agent that wants more information about the namespace.

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

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

4.6.5. Fragment Identifiers and ID Semantics

The section on media types and fragment identifier semantics discusses the interpretation of fragment identifiers. Per the previous good practice note on fragment identifiers, designers of an XML-based 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 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 and it is problematic in practice.

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

  1. 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.
  2. Processing the document with a W3C XML Schema might reveal an element declaration that identifies the name attribute as an xs:ID.
  3. In practice, processing the document with another schema language, such as RELAX NG, might reveal the attributes of type ID. Many modern specifications begin processing XML at the 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, or PSVI) may successfully 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.

Editor's note: W3C's XML Core Working Group is investigating the question of fragment identifier semantics.

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

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

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

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 text/*

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

4.7. Future Directions for Formats

There remain open questions regarding resource representations. The following sections identify a few areas of future work in the Web community. The TAG makes no commitment at this time to pursuing these issues.

4.7.1. Composition of Data Formats

Many modern data format specifications include mechanisms for composition. These mechanisms range from relatively shallow and limited to relatively deep and sophisticated.

Toward the shallow end of the spectrum, 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 content of the image.

Towards the deep end, it is possible to compose XML documents with elements from a variety of namespaces. How these namespaces interact and what effect an element's namespace has on its ancestors, siblings, and descendents is not always obvious.

Near the middle of the spectrum, 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.

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

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

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

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

TAG issue RDFinXHTML-35: Syntax and semantics for embedding RDF in XHTML

5. Conformance

This document defines conformance profiles for the following types of entities:

To conform as a given entity type, a claimant must satisfy all of the good practice notes having that entity type as subject and that include the phrase "MUST" or "MUST NOT". The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are thus used in accordance with RFC 2119 [RFC2119].

The existence of a conformance claim does not imply that W3C has reviewed the claim or assured its validity. As of the publication of this document, W3C does not act as an assuring party, but it may do so in the future, or it may establish recommendations for assuring parties.

6. Glossary

Glossary not yet completed.

6.1. Principles, Constraints, etc.

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

The important points of this document are categorized as follows:

An architectural constraint is a restriction in behavior or interaction within the system. Constraints may be imposed for technical, policy, or other reasons.
Design Choice
In the design of the Web, some design choices, like the names of the <p> and <li> elements in HTML, or the choice of the colon character in URIs, are somewhat arbitrary; if <par>, <elt>, or * had been chosen instead, the large-scale result would, most likely, have been the same. Other design choices are more fundamental; these are the focus of this document.
Good practice
Good practice — by software developers, content authors, site managers, users, and specification writers — increases the value of the Web.
An architectural principle is a fundamental 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."
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.

7. Index

8. References

8.1. Normative References

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

8.2. Architectural Specifications

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

8.3. Non-Normative References

"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.
"DAML+OIL (March 2001) Reference Description", D. Connolly, F. van Harmelen, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, 18 Dec 2001. This W3C Note is available at http://www.w3.org/TR/2001/NOTE-daml+oil-reference-20011218.
"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.
"Knowledge-Domain Interoperability and an Open Hyperdocument System", D. C. Engelbart, June 1990.
Dan Connolly's list of URI schemes is a useful resource for finding out which references define various URI schemes.
IETF "Guidelines For The Use of XML in IETF Protocols," S. Hollenbeck, M. Rose, L. Masinter, eds., 2 November 2002. This IETF Internet Draft is available at http://www.imc.org/ietf-xml-use/xml-guidelines-07.txt. If this document is no longer available, refer to the ietf-xml-use mailing list.
IETF " Internationalized Resource Identifiers (IRIs)", M. Duerst, M. Suignard, Nov 2002. This IETF Internet Draft is available at http://www.w3.org/International/iri-edit/draft-duerst-iri.html. If this document is no longer available, refer to the home page for Editing 'Internationalized Resource Identifiers (IRIs)'.
"Web Ontology Language (OWL) Reference Version 1.0", M. Dean and G. Schreiber, eds., 18 August 2003. This W3C Candidate Recommendation is available at http://www.w3.org/TR/2003/CR-owl-ref-20030818/.
"The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", M. Marchiori, ed., 16 April 2002. This W3C Recommendation is available at http://www.w3.org/TR/2002/REC-P3P-20020416/.
"Resource Directory Description Language (RDDL)", J. Borden, T. Bray, eds., 1 June 2003. This document is available at http://www.tbray.org/tag/rddl/rddl3.html.
"Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. R. Swick, eds., 22 February 1999. This W3C Recommendation is available at http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.
" Representational State Transfer (REST)", Chapter 5 of "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Thesis of R. T. Fielding, 2000. Available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.
IETF "RFC 2141: URN Syntax", R. Moats, May 1997. Available at http://www.ietf.org/rfc/rfc2141.txt.
IETF "Guidelines for new URL Schemes", L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, November 1999. Available at: http://www.ietf.org/rfc/rfc2718.txt.
IETF "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, January 2001. Available at: http://www.rfc-editor.org/rfc/rfc3023.txt
IETF "RFC 3236: The 'application/xhtml+xml' Media Type", M. Baker, P. Stark, January 2002. Available at: http://www.rfc-editor.org/rfc/rfc3236.txt
IETF "RFC 3401: Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", M. Mealing, October 2002. Available at: http://www.rfc-editor.org/rfc/rfc3401.txt
"SOAP Version 1.2 Part 1: Messaging Framework", M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, H. Frystyk Nielsen, eds., 24 June 2003. This W3C Recommendation is available at http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.
"Scalable Vector Graphics (SVG) 1.1 Specification", J. Ferraiolo, Fujisawa Jun, D. Jackson, eds., 14 January 2003. This W3C Recommendation is available at http://www.w3.org/TR/2003/REC-SVG11-20030114/.
See the Unicode Consortium home page for information about the latest version of Unicode and character repertoires.
" 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.
"XHTML 1.0: The Extensible HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0", S. Pemberton et al., 26 January 2000, revised 1 August 2002. Available at http://www.w3.org/TR/2002/REC-xhtml1-20020801/.
"XML Schema Part 1: Structures", H. Thompson, D. Beech, M. Maloney, N. Mendelsohn, 2 May 2001. Available at http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ .
"XML Linking Language (XLink) Version 1.0", S. DeRose, E. Maler, D. Orchard, 27 June 2001. This W3C Recommendation is available at http://www.w3.org/TR/2001/REC-xlink-20010627/.
"Extensible Markup Language (XML) 1.0 (Second Edition)", T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler, 6 October 2000. This W3C Recommendation is available at http://www.w3.org/TR/2000/REC-xml-20001006.
"Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14 Jan 1999. This W3C Recommendation is available at http://www.w3.org/TR/1999/REC-xml-names-19990114/.
"XPointer Framework", P. Grosso, E. Maler, J. Marsh, N. Walsh, eds., 25 March 2003. This W3C Recommendation is available at http://www.w3.org/TR/2003/REC-xptr-framework-20030325/.

9. Acknowledgments

This document was authored by the W3C Technical Architecture Group which included the following participants: Tim Berners-Lee (co-Chair, W3C), Tim Bray (Antarctica Systems), Dan Connolly (W3C), Paul Cotton (Microsoft Corporation), Roy Fielding (Day Software), Chris Lilley (W3C), David Orchard (BEA Systems), Norman Walsh (Sun), and Stuart Williams (co-Chair, Hewlett-Packard).

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