About this Document

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

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

This document does not include conformance provisions for these reasons:

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

Benefits of URIs

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

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

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

URI/Resource Relationships

By design a URI identifies one resource. We do not limit the scope of what might be a resource. The term "resource" is used in a general sense for whatever might be identified by a URI. It is conventional on the hypertext Web to describe Web pages, images, product catalogs, etc. as “resources”. The distinguishing characteristic of these resources is that all of their essential characteristics can be conveyed in a message. We identify this set as “information resources.”

This document is an example of an information resource. It consists of words and punctuation symbols and graphics and other artifacts that can be encoded, with varying degrees of fidelity, into a sequence of bits. There is nothing about the essential information content of this document that cannot in principle be transfered in a message. In the case of this document, the message payload is the representation of this document.

However, our use of the term resource is intentionally more broad. Other things, such as cars and dogs (and, if you've printed this document on physical sheets of paper, the artifact that you are holding in your hand), are resources too. They are not information resources, however, because their essence is not information. Although it is possible to describe a great many things about a car or a dog in a sequence of bits, the sum of those things will invariably be an approximation of the essential character of the resource.

We define the term “information resource” because we observe that it is useful in discussions of Web technology and may be useful in constructing specifications for facilities built for use on the Web.

Since 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 indirect identification).

[[!URI]] is an agreement about how the Internet community allocates names and associates them with the resources they identify. URIs are divided into schemes that define, via their scheme specification, the mechanism by which scheme-specific identifiers are associated with resources. For example, the "http" URI scheme ([[!HTTP11]]) uses DNS and TCP-based HTTP servers for the purpose of identifier allocation and resolution. As a result, identifiers such as "http://example.com/somepath#someFrag" often take on meaning through the community experience of performing an HTTP GET request on the identifier and, if given a successful response, interpreting the response as a representation of the identified resource. (See also Fragment Identifiers.) Of course, a retrieval action like GET is not the only way to obtain information about a resource. One might also publish a document that purports to define the meaning of a particular URI. These other sources of information may suggest meanings for such identifiers, but it's a local policy decision whether those suggestions should be heeded.

Just as one might wish to refer to a person by different names (by full name, first name only, sports nickname, romantic nickname, and so forth), Web architecture allows the association of more than one URI with a resource. URIs that identify the same resource are called URI aliases. The section on URI aliases discusses some of the potential costs of creating multiple URIs for the same resource.

Several sections of this document address questions about the relationship between URIs and resources, including:

• How much can I tell about a resource by inspection of a URI that identifies it? See the sections on URI schemes and URI opacity.
• Who determines what resource a URI identifies? See the section on URI allocation.
• Can the resource identified by a URI change over time? See the sections on URI persistence and representation management .
• Since more than one URI can identify the same resource, how do I know which URIs identify the same resource? See the sections on URI comparison and assertions that two URIs identify the same resource.

URI Comparisons

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

To reduce the risk of a false negative (i.e., an incorrect conclusion that two URIs do not refer to the same resource) or a false positive (i.e., an incorrect conclusion that two URIs do refer to the same resource), some specifications describe equivalence tests in addition to character-by-character comparison. Agents that reach conclusions based on comparisons that are not licensed by the relevant specifications take responsibility for any problems that result; see the section on error handling for more information about responsible behavior when reaching unlicensed conclusions. Section 6 of [[!URI]] provides more information about comparing URIs and reducing the risk of false negatives and positives.

See also the assertion that two URIs identify the same resource.

URI Schemes

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

Examples of URIs from various schemes include:

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

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

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

Consider our travel scenario: should the agent providing information about the weather in Oaxaca register a new URI scheme "weather" for the identification of resources related to the weather? They might then publish URIs such as "weather://travel.example.com/oaxaca". When a software agent dereferences such a URI, if what really happens is that HTTP GET is invoked to retrieve a representation of the resource, then an "http" URI would have sufficed.

URI Opacity

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

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

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

The example URI used in the travel scenario ("http://weather.example.com/oaxaca") suggests to a human reader that the identified resource has something to do with the weather in Oaxaca. A site reporting the weather in Oaxaca could just as easily be identified by the URI "http://vjc.example.com/315". And the URI "http://weather.example.com/vancouver" might identify the resource "my photo album."

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

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

Fragment Identifiers

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

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

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

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

Future Directions for Identifiers

There remain open questions regarding identifiers on the Web.

Using a URI to Access a Resource

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

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

Although many URI schemes are named after protocols, this does not imply that use of such a URI will necessarily result in access to the resource via the named protocol. Even when an agent uses 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.

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

Representation Types and Internet Media Types

A representation is data that encodes information about resource state. Representations do not necessarily describe the resource, or portray a likeness of the resource, or represent the resource in other senses of the word "represent".

Representations of a resource may be sent or received using interaction protocols. These protocols in turn determine the form in which representations are conveyed on the Web. HTTP, for example, provides for transmission of representations as octet streams typed using Internet media types [RFC2046].

Just as it is important to reuse existing URI schemes whenever possible, there are significant benefits to using media typed octet streams for representations even in the unusual case where a new URI scheme and associated protocol is to be defined. For example, if the Oaxaca weather were conveyed to Nadia's browser using a protocol other than HTTP, then software to render formats such as text/xhmtl+xml and image/png would still be usable if the new protocol supported transmission of those types. This is an example of the principle of orthogonal specifications.

The Internet media type mechanism does have some limitations. For instance, media type strings do not support versioning or other parameters. See TAG issues uriMediaType-9 and mediaTypeManagement-45 which concern aspects of the media type mechanism.

Inconsistencies between Representation Data and Metadata

Successful communication between two parties depends on a reasonably shared understanding of the semantics of exchanged messages, both data and metadata. At times, there may be inconsistencies between a message sender's data and metadata. Examples, observed in practice, of inconsistencies between representation data and metadata include:

• The actual character encoding of a representation (e.g., "iso-8859-1", specified by the encoding attribute in an XML declaration) is inconsistent with the charset parameter in the representation metadata (e.g., "utf-8", specified by the 'Content-Type' field in an HTTP header).
• The namespace of the root element of XML representation data (e.g., as specified by the "xmlns" attribute) is inconsistent with the value of the 'Content-Type' field in an HTTP header.

On the other hand, there is no inconsistency in serving HTML content with the media type "text/plain", for example, as this combination is licensed by specifications.

Receiving agents should detect protocol inconsistencies and perform proper error recovery.

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 ignore the problem (e.g., by simply rendering the JPEG image) without Nadia's consent. Nadia's browser can notify Nadia of the problem or notify Nadia and take corrective action.

Furthermore, representation providers can help reduce the risk of inconsistencies 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.

The accuracy of metadata relies on the server administrators, the authors of representations, and the software that they use. Practically, the capabilities of the tools and the social relationships may be the limiting factors.

The accuracy of these and other metadata fields is just as important for dynamic Web resources, where a little bit of thought and programming can often ensure correct metadata for a huge number of resources.

Often there is a separation of control between the users who create representations of resources and the server managers who maintain the Web site software. Given that it is generally the Web site software that provides the metadata associated with a resource, it follows that coordination between the server managers and content creators is required.

In particular, content creators need to be able to control the content type (for extensibility) and the character encoding (for proper internationalization).

The TAG finding "Authoritative Metadata" discusses in more detail how to handle data/metadata inconsistency and how server configuration can be used to avoid it.

Safe Interactions

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. Note: In this context, the word "unsafe" does not necessarily mean "dangerous"; the term "safe" is used in section 9.1.1 of [[!HTTP11]] and "unsafe" is the natural opposite.

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 hypertext links safely. Users (or agents acting on their behalf) do not commit themselves to anything by querying a resource or following a hypertext link.

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

The fact that HTTP GET, the access method most often used when following a hypertext link, is safe does not imply that all safe interactions must be done through HTTP GET. At times, there may be good reasons (such as confidentiality requirements or practical limits on URI length) to conduct an otherwise safe operation using a mechanism generally reserved for unsafe operations (e.g., HTTP POST).

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

Representation Management

A URI owner may supply zero or more authoritative representations of the resource identified by that URI. There is a benefit to the community in providing representations.

For example, owners of XML namespace URIs should use them to identify a namespace document.

Just because representations are available does not mean that it is always desirable to retrieve them. In fact, in some cases the opposite is true.

Dereferencing a URI has a (potentially significant) cost in computing and bandwidth resources, may have security implications, and may impose significant latency on the dereferencing application. Dereferencing URIs should be avoided except when necessary.

The following sections discuss some aspects of representation management, including promoting URI persistence, managing access to resources, and supporting navigation.

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, peer-to-peer systems, instant messaging systems (such as [[!RFC3920]]), streaming audio (such as RTSP [[!RFC2326]]), and voice-over-IP (such as SIP [[!RFC3261]]).

Binary and Textual Data Formats

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

A textual data format is one in which the data is specified in a defined encoding as a sequence of characters. HTML, Internet e-mail, and all XML-based formats are textual. Increasingly, internationalized textual data formats refer to the Unicode repertoire [[!UNICODE]] for character definitions.

If a data format is textual, as defined in this section, that does not imply that it should be served with a media type beginning with "text/". Although XML-based formats are textual, many XML-based formats do not consist primarily 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.

In principle, all data can be represented using textual formats. In practice, some types of content (e.g., audio and video) are generally represented using binary 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. Note, however, that such cases are relatively uncommon as such direct use may open the door to security issues that can only practically be addressed by examining every aspect of the data structure in detail.

Textual formats are usually more portable and interoperable. Textual formats also have the considerable advantage that they can be directly read by human beings (and understood, given sufficient documentation). 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; this is called the "view source" effect.

It is important to emphasize that intuition as to such matters as data size and processing speed is not a reliable guide in data format design; quantitative studies are essential to a correct understanding of the trade-offs. Therefore, designers of a data format specification should make a considered choice between binary and textual format design.

See TAG issue binaryXML-30.

Versioning and Extensibility

In a perfect world, language designers would invent languages that perfectly met the requirements presented to them, the requirements would be a perfect model of the world, they would never change over time, and all implementations would be perfectly interoperable because the specifications would have no variability.

In the real world, language designers imperfectly address the requirements as they interpret them, the requirements inaccurately model the world, conflicting requirements are presented, and they change over time. As a result, designers negotiate with users, make compromises, and often introduce extensibility mechanisms so that it is possible to work around problems in the short term. In the long term, they produce multiple versions of their languages, as the problem, and their understanding of it, evolve. The resulting variability in specifications, languages, and implementations introduces interoperability costs.

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 about how these strategies introduce variability and how that variability impacts interoperability, see Variability in Specifications.

See TAG issue XMLVersioning-41, which concerns good practices for designing extensible XML languages and for handling versioning. See also "Web Architecture: Extensible Languages" [[!EXTLANG]].

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 mobile 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 separation of content, presentation, and interaction promotes the reuse and device-independence of content; this follows from the principle of orthogonal specifications.

This separation also facilitates reuse of authored source content across multiple delivery contexts. Sometimes, functional user experiences suited to any delivery context can be generated by using an adaptation process applied to a representation that does not depend on the access mechanism. For more information about principles of device-independence, see [DIPRINCIPLES].

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 approach. For instance when a client (such as a mobile phone) communicates device capabilities to the server (for example, using CC/PP), the server can tailor the delivered content to fit that client. The server can, for example, enable faster downloads by adjusting links to refer to lower resolution images, smaller video or no video at all. Similarly, if the content has been authored with multiple branches, the server can remove unused branches before delivery. In addition, by tailoring the content to match the characteristics of a target client, the server can help reduce client side computation. However, specializing content in this manner reduces caching efficiency.

On the other hand, designing content that that can be recombined on the client also tends to make that content applicable to a wider range of devices. This design also improves caching efficiency and offers users more presentation options. Media-dependent style sheets can be used to tailor the content on the client side to particular groups of target devices. For textual content with a regular and repeating structure, the combined size of the text content plus the style sheet is typically less than that of fully recombined content; the savings improve further if the style sheet is reused by other pages.

In practice a combination of both approaches is often used. The design decision about where on this spectrum an application should be placed depends on the power on the client, the power and the load on the server, and the bandwidth of the medium that connects them. If the number of possible clients is unbounded, the application will scale better if more computation is pushed to the client.

Of course, it may not be desirable to reach the widest possible audience. Designers should consider appropriate technologies, such as encryption and access control, for limiting the audience.

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 (concerning interoperability in the case of formatting properties and names) and contentPresentation-26 (concerning the separation of semantic and presentational markup).

Hypertext

A defining characteristic of the Web is that it allows embedded references to other resources via URIs. The simplicity of creating hypertext 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 success 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). Note: In this document, the term "link" generally means "relationship", not "physical connection".

Formats that allow content authors to use URIs instead of local identifiers promote the network effect: the value of these formats grows with the size of the deployed Web.

What agents do with a hypertext link is not constrained by Web architecture and may depend on application context. Users of hypertext links expect to be able to navigate among representations by following links.

Data formats that do not allow content authors to create hypertext links lead to the creation of "terminal nodes" on the Web.

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]] or [XML11]. 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.

Future Directions for Data Formats

Data formats enable the creation of new applications to make use of the information space infrastructure. The Semantic Web is one such application, built on top of RDF [RDFXML]. This document does not discuss the Semantic Web in detail; the TAG expects that future volumes of this document will. See the related TAG issue httpRange-14.

Orthogonal Specifications

Identification, interaction, and representation are orthogonal concepts, meaning that technologies used for identification, interaction, and representation may evolve independently. For instance:

• Resources are identified with URIs. URIs can be published without building any representations of the resource or determining whether any representations are available.
• A generic URI syntax allows agents to function in many cases without knowing specifics of URI schemes.
• In many cases one may change the representation of a resource without disrupting references to the resource (for example, by using content negotiation).

When two specifications are orthogonal, one may change one without requiring changes to the other, even if one has dependencies on the other. For example, although the HTTP specification depends on the URI specification, the two may evolve independently. This orthogonality increases the flexibility and robustness of the Web. For example, one may refer by URI to an image without knowing anything about the format chosen to represent the image. This has facilitated the introduction of image formats such as PNG and SVG without disrupting existing references to image resources.

Experience demonstrates that problems arise where orthogonal concepts occur in a single specification. Consider, for example, the HTML specification which includes the orthogonal x-www-form-urlencoded specification. Software 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.

Problems also arise when specifications attempt to modify orthogonal abstractions described elsewhere. An historical version of the HTML specification added a "Refresh" value to the http-equiv attribute of the meta element. It was defined to be equivalent to the HTTP header of the same name. The authors of the HTTP specification ultimately decided not to provide this header and that made the two specifications awkwardly at odds with each other. The W3C HTML Working Group eventually removed the "Refresh" value.

A specification should clearly indicate which features overlap with those governed by another specification.

Extensibility

The information in the Web and the technologies used to represent that information change over time. Extensibility is the property of a technology that promotes evolution without sacrificing interoperability. Some examples of successful technologies designed to allow change while minimizing disruption include:

• the fact that URI schemes are orthogonally 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.

An example of an unsuccessful extension mechanism is HTTP mandatory extensions [HTTPEXT]. The community has sought mechanisms to extend HTTP, but apparently the costs of the mandatory extension proposal (notably in complexity) outweighed the benefits and thus hampered adoption.

Below we discuss the property of "extensibility," exhibited by URIs, some data formats, and some protocols (through the incorporation of new messages).

Subset language: 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.

Extended language: If one language is a subset of another, the latter superset is called an extended language; the difference between the languages is called the extension. Clearly, extending a 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 can evolve this way, allowing applications to provide new information when necessary while still interoperating with applications that only understand a subset of the current language, are said to be "extensible." Language designers can facilitate extensibility by defining the default behavior of unknown extensions—for example, that they be ignored (in some defined way) or should be considered errors.

For example, from early on in the Web, HTML agents followed the convention of ignoring unknown tags. 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 and HTML Dialects.

Error Handling

Errors occur in networked information systems. An error condition can be well-characterized (e.g., well-formedness errors in XML or 4xx client errors in HTTP) or arise unpredictably. Error correction means that an agent repairs a condition so that within the system, it is as though the error never occurred. One example of error correction involves data retransmission in response to a temporary network failure. Error recovery means that an agent does not repair an error condition but continues processing by addressing the fact that the error has occurred.

Agents frequently correct errors without user awareness, sparing users the details of complex network communications. On the other hand, it is important that agents recover from error in a way that is evident to users, since the agents are acting on their behalf.

An agent is not required to interrupt the user (e.g., by popping up a confirmation box) to obtain consent. The user may indicate consent through pre-selected configuration options, modes, or selectable user interface toggles, with appropriate reporting to the user when the agent detects an error. Agent developers should not ignore usability issues when designing error recovery behavior.

To promote interoperability, specification designers should identify predictable error conditions. Experience has led to the following observations about error-handling approaches.

• Protocol designers should provide enough information about an error condition so that an agent can address the error condition. For instance, an HTTP 404 status code (not found) is useful because it allows user agents to present relevant information to users, enabling them to contact the representation provider in case of problems.
• Experience with the cost of building a user agent to handle the diverse forms of ill-formed HTML content convinced the designers of the XML specification to require that agents fail 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 by considering it 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 issue contentTypeOverride-24, which concerns the source of authoritative metadata.

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 sequencing constraints of the messages interchanged. Protocols designed to be resilient in the face of widely varying environments have helped the Web scale and have facilitated communication across multiple trust boundaries. Traditional application programming interfaces (APIs) do not always take these constraints into account, nor should they be required to. One effect of protocol-based design is that the technology shared among agents often 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. It is often desirable to provide users with access to format and protocol details: allowing them to “view source,” whereby they may gain expertise in the workings of the underlying system.

References

CGI

Common Gateway Interface/1.1 Specification. Available at http://hoohoo.ncsa.uiuc.edu/cgi/interface.html.

CHIPS

Common HTTP Implementation Problems, O. Théreaux, January 2003. This W3C Team Submission is available at http://www.w3.org/TR/chips/.

CUAP

Common User Agent Problems, K. Dubost, January 2003. This W3C Team Submission is available at http://www.w3.org/TR/cuap.

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.

HTTPEXT

Mandatory Extensions in HTTP, H. Frystyk Nielsen, P. Leach, S. Lawrence, 20 January 1998. This expired IETF Internet Draft is available at http://www.w3.org/Protocols/HTTP/ietf-http-ext/draft-frystyk-http-mandatory.

IANASchemes

IANA's online registry of URI Schemes is available at http://www.iana.org/assignments/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.

INFOSET

XML Information Set (Second Edition), R. Tobin, J. Cowan, Editors, W3C Recommendation, 04 February 2004, http://www.w3.org/TR/2004/REC-xml-infoset-20040204. Latest version available at http://www.w3.org/TR/xml-infoset.

IRI

IETF Internationalized Resource Identifiers (IRIs), M. Dürst, 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)'.

MEDIATYPEREG

IANA's online registry of Internet Media Types is available at http://www.iana.org/assignments/media-types/index.html.

OWL10

OWL Web Ontology Language Reference, M. Dean, G. Schreiber, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/. Latest version available at http://www.w3.org/TR/owl-ref/.

P3P10

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification, M. Marchiori, Editor, W3C Recommendation, 16 April 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/. Latest version available at http://www.w3.org/TR/P3P/.

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.

RDFXML

RDF/XML Syntax Specification (Revised), D. Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. Latest version available at http://www.w3.org/TR/rdf-syntax-grammar.

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. Designers of protocol specifications in particular should invest time in understanding the REST model and the relevance of its principles to a given design. These principles include statelessness, clear assignment of roles to parties, uniform address space, and a limited, uniform set of verbs. Available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.

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.

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.

RFC2397

IETF RFC 2397: The “data” URL scheme, L. Masinter, August 1998. Available at: http://www.ietf.org/rfc/rfc2397.txt.

RFC2616

IETF RFC 2616: Hypertext Transfer Protocol - HTTP/1.1, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt.

RFC2717

IETF Registration Procedures for URL Scheme Names, R. Petke, I. King, November 1999. Available at http://www.ietf.org/rfc/rfc2717.txt.

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.ietf.org/rfc/rfc3023.txt

RFC3236

IETF RFC 3236: The 'application/xhtml+xml' Media Type, M. Baker, P. Stark, January 2002. Available at: http://www.ietf.org/rfc/rfc3236.txt

RFC3261

IETF RFC 3261: SIP: Session Initiation Protocol, J. Rosenberg, H. Schulzrinne, G. Camarillo, et. al., June 2002. Available at: http://www.ietf.org/rfc/rfc3261.txt

RFC3920

IETF RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core, P. Saint-Andre, Ed., October 2004. Available at: http://www.ietf.org/rfc/rfc3920.txt

RFC977

IETF RFC 977: Network News Transfer Protocol, B. Kantor, P. Lapsley, February 1986. Available at http://www.ietf.org/rfc/rfc977.txt.

SOAP12

SOAP Version 1.2 Part 1: Messaging Framework, J. Moreau, N. Mendelsohn, H. Frystyk Nielsen, et. al., 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/.

UNICODE

See the Unicode Consortium home page for information about the latest version of Unicode and character repertoires.

URI

Uniform Resource Identifiers (URI): Generic Syntax (T. Berners-Lee, R. Fielding, L. Masinter, Eds.) is currently being revised. Citations labeled [[!URI]] refer to "Uniform Resource Identifier (URI): Generic Syntax."

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.

VOICEXML2

Voice Extensible Markup Language (VoiceXML) Version 2.0, B. Porter, A. Hunt, K. Rehor, et. al., Editors, W3C Recommendation, 16 March 2004, http://www.w3.org/TR/2004/REC-voicexml20-20040316/. Latest version available at http://www.w3.org/TR/voicexml20.

XHTML11

XHTML™ 1.1 - Module-based XHTML, S. McCarron, M. Altheim, 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/.

XLink10

XML Linking Language (XLink) Version 1.0, E. Maler, S. DeRose, 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/.

XML-ID

xml:id Version 1.0, D. Veillard, J. Marsh, Editors, W3C Working Draft (work in progress), 07 April 2004, http://www.w3.org/TR/2004/WD-xml-id-20040407. Latest version available at http://www.w3.org/TR/xml-id/.

XML10

Extensible Markup Language (XML) 1.0 (Third Edition), F. Yergeau, J. Paoli, C. M. Sperberg-McQueen, et. al., Editors, W3C Recommendation, 04 February 2004, http://www.w3.org/TR/2004/REC-xml-20040204. Latest version available at http://www.w3.org/TR/REC-xml.

XML11

Extensible Markup Language (XML) 1.1, J. Paoli, C. M. Sperberg-McQueen, J. Cowan, et. al., Editors, W3C Recommendation, 04 February 2004, http://www.w3.org/TR/2004/REC-xml11-20040204/. Latest version available at http://www.w3.org/TR/xml11/.

XMLNS

Namespaces in XML 1.1, R. Tobin, D. Hollander, A. Layman, et. al., Editors, W3C Recommendation, 04 February 2004, http://www.w3.org/TR/2004/REC-xml-names11-20040204. Latest version available at http://www.w3.org/TR/xml-names11/.

XMLSCHEMA

XML Schema Part 1: Structures, D. Beech, M. Maloney, H. S. Thompson, et. al., Editors, W3C Recommendation, 02 May 2001, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/. Latest version available at http://www.w3.org/TR/xmlschema-1/.

XPTRFR

XPointer Framework, E. Maler, N. Walsh, P. Grosso, et. al., 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, Editor, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/1999/REC-xslt-19991116. Latest version available at http://www.w3.org/TR/xslt.