Architecture of the World Wide Web, First Edition

List of Principles, Constraints, and Good Practice Notes

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

deleted text: General Architecture Principles </dt> <dd> <ul> <li> <a href="#no-silent-recovery"> Error recovery </a> (principle, 1.2.3) </li> </ul> </dd> <dt> Identification

• Global Identifiers (principle, 2)
• Identify with URIs (practice, 2.1)
• Avoiding URI aliases (practice, 2.3.1)
• Consistent URI usage (practice, 2.3.1)
• Avoiding URI Overloading (practice, 2.4)
• <a href="#pr-new-scheme-expensive"> New Reuse URI schemes (practice, 2.6)
• URI opacity (practice, 2.7)

Interaction

• Data-metadata inconsistency (principle, 3.4)
• Safe retrieval (principle, 3.5)
• Available representation (practice, 3.6)
• Consistent representation (practice, 3.6.1)

Data Formats

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

General Architecture Principles

• Error recovery (principle, 5.3)

1.1. About this Document

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

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

2.1. Benefits of URIs

The choice of syntax for global identifiers is somewhat arbitrary; what is important is their global scope. The Uniform Resource Identifier ([ URI ], currently being revised) deleted text: mechanism 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. A resource should be assigned a 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 it will prove useful to be able to share sharing a URI across applications, 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.

Other mechanisms for identifying resources resource identification systems (see the section on future directions for identifiers ) may expand the Web as we know it today. However, there are substantial costs to creating a new identification mechanism system that has the same properties as URIs.

2.2. URI/Resource Relationships

To keep communication costs down, by design a URI identifies one resource. resource . 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 ).

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 assignment association of more than one URI to with a resource. URIs that identify the same resource are called URI aliases </a> . The section on URI aliases discusses some of the potential costs of creating multiple URIs for the same resource.

The following sections address other 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 in particular the sections on URI schemes and Information Resources .
• Who determines what resource a URI identifies? See the section on URI ownership .
• Can the resource identified by a URI change over time? See in particular 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 in particular the sections on URI comparison and assertions that two URIs identify the same resource .
deleted text: <li> Are there resources that are not identified by any URI? In a system where the only resource identification mechanism is the URI, the question is only of philosophical interest (similarly, if a tree falls in the forest and nobody is around to hear it, does it make a sound?). The advent of other resource identification mechanisms may change the nature of this question and answer. </li>

2.3. URI Comparisons

The most straightforward way of establishing that two parties are referring to the same resource is to compare, character-by-character, the URIs they are using. Two used in making the reference; two URIs that are identical deleted text: (character for character) refer to the same resource. Because Web architecture allows the assignment association of more than one URI to with a resource, two URIs that are not character for character character-by-character identical can still refer to the same resource (i.e., they do not necessarily refer to different resources). There is generally a higher computational cost to determine that two 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), certain specifications license applications to apply specify equivalence tests in addition to character-by-character comparison. For example, for "http" URIs, the authority component (the part after "//" and before the next "/") is defined to be case-insensitive. Thus, the "http" URI specification licenses applications allows agents to conclude that authority components in two "http" URIs are equivalent identify the same resource when those strings are character-by-character equivalent or differ only by case. Agents that reach conclusions based on comparisons that are not licensed specified by relevant specifications take responsibility for any problems that result. result; see the section on error handling [section 5.3] 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 the section below on approaches other than string comparison that allow different parties agents to <a href="#future-comparison" shape="rect"> assert conclude that two URIs identify the same resource [section 2.9.2] .

2.4. URI Overloading

As discussed above, a URI identifies one resource. At times, agents may intentionally or unintentionally use a URI to identify different resources. URI overloading refers to the use of one URI to refer directly to more than one resource. Overloading often imposes a cost in communication due to the effort required to resolve ambiguities.

Suppose, for example, that one organization makes use of a URI to refer to the movie "The Sting", and another organization uses the same URI to refer to a discussion forum about "The Sting." This overloading can create confusion about what the URI identifies, undermining the value of the URI. If one wanted to talk about the creation date of the resource identified by the URI, for instance, it would not be clear whether this meant "when the movie created" or "when the discussion forum about the movie was created."

The section below on <a href="#uri-ownership" shape="rect"> URI ownership [section 2.5] examines approaches for establishing the authoritative source of information about what resource a URI identifies.

2.5. URI Ownership

To avoid URI overloading , it is important to reduce the risk that different agents will unintentionally (or intentionally) create use the same URI (i.e., sequence of characters). URI scheme specifications can help reduce this risk, and commonly do so through the hierarchical delegation of authority. This approach, exemplified by the "http" and "mailto" schemes, allows the assignment of a part of URI space to one party, who may, in turn, delegate management of pieces of that space to other parties.

It is thus useful for a URI scheme to establish a unique relationship between a social entity and a URI; this is the case for the "http", "mailto", "mid", and "cid" schemes, for example. This relationship is called URI ownership . In this document, the phrase "authority responsible for domain X" indicates that the same entity owns those URIs where the authority component is domain X. This document does not address how the benefits and responsibilities of URI ownership may be delegated to other parties, such as to a server manager or to someone who has been delegated part of the URI space on a given Web server.

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

A URI owner may, upon request, provide representations of the resource identified by the URI. For example, when a URI owner uses the HTTP protocol to provide those representations, the HTTP origin server (defined in [ RFC2616 ]) is the software agent acting on behalf of the URI owner to provide the authoritative representations for the resource identified by that URI. The owner is also responsible for accepting or rejecting requests to modify the resource identified by that URI, for example, by configuring a server to accept or reject HTTP PUT data based on Internet media type, validity constraints, or other constraints.

Recall that the Web architecture allows different URI owners to create URI aliases . This means that multiple parties may provide representations of the same resource, depending on which URI is used for interaction. A URI owner's rights extend only to the representations served for requests given that URI.

There are social expectations for responsible <a href="#representation-management" shape="rect"> representation management [section 3.6] by URI owners, discussed below. Additional social implications of URI ownership are not discussed here. However, the success or failure of these different approaches depends on the extent to which there is consensus in the Internet community on abiding by the defining specifications.

See TAG issue siteData-36 , which concerns the expropriation of naming authority.

2.6. 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 how identifiers are assigned within that scheme. The URI syntax is thus a federated and extensible naming mechanism 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 the Web architecture allows the definition of new schemes, introducing a new scheme is costly. Many aspects of URI processing are scheme-dependent, and a significant amount of deployed software already processes URIs of well-known schemes. Introducing a new URI scheme requires the development and deployment not only of client software to handle the scheme, but also of ancillary agents such as gateways, proxies, and caches. See [ RFC2718 ] for other considerations and costs related to URI scheme design.

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

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

If the motivation behind registering a new scheme is to allow a software agent to launch a particular application when retrieving a representation, such dispatching can be accomplished at lower expense via Internet media types. When designing a new data format, the appropriate mechanism to promote its deployment on the Web is the Internet media type. Media types also provide a means for <a href="#media-types-infospace" shape="rect"> building new information space applications [section 4.6] , described below.

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

2.7. URI Opacity

It is tempting to guess the nature of a resource by inspection of a URI that identifies it. However, the Web is designed so that agents communicate resource information state through representations , not identifiers. In general, one cannot determine the Internet media type of representations of a resource by inspecting a URI for that resource. For example, the ".html" at the end of "http://example.com/page.html" provides no guarantee that representations of the identified resource will be served with the Internet media type "text/html". The HTTP protocol does not constrain the Internet media type based on the path component of the URI; the 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 links. references. For robustness, Web architecture promotes independence between an identifier and the identified resource.

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

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

In some cases, relevant technical specifications license allow URI assignment authorities to publish assignment policies. For more information about URI opacity, see TAG issue <a href="http://www.w3.org/2001/tag/ilist#metadataInURI-31" shape="rect"> metaDataInURI-31 .

2.8. 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 interpretation of fragment identifiers is discussed in the section on media types and fragment identifier semantics .

See TAG issues issue abstractComponentRefs-37 </a> and <a href="http://www.w3.org/2001/tag/issues.html#DerivedResources-43" shape="rect"> DerivedResources-43 </a>. , which concerns the use of fragment identifiers with namespace names to identify abstract components.

2.9. Future Directions for Identifiers

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

3.1. Information Resources and Representations

The term Information Resource refers to the class of resources having information state — — state that can be represented as octets. A representation of information state consists logically of two parts: data (expressed in one or more formats used separately or in combination) and metadata (such as the Internet media type of the data).

The Information Resource provides the foundation for the familiar hypertext Web, where agents use representations to modify as well as retrieve information state. Much of this document describes architecture specific to Information Resources. For instance, the techniques of caching and content negotiation , and the social processes of publishing, apply to Information Resources.

3.2. 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 mechanism 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 mechanisms, methods, others (such as the URN scheme [ RFC 2141 ]) do not. Section 1.2.2 of [ URI ] discusses the separation of identification and interaction in more detail. For more information about relationships between multiple access mechanisms 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.

3.3. Internet Media Type

The Internet media type [ RFC2046 ]) of a representation determines which data format specification(s) provide the authoritative interpretation of the representation data (including fragment identifier syntax and semantics , if any). The IANA registry [ MEDIATYPEREG ] maps media types to data formats . The TAG finding " Internet media type registration, consistency of use " provides more information to W3C groups about media type registration.

Internet media type mechanism does have its limitations. For instance, media type strings do not support versioning or other parameters. The See TAG issue mediaTypeManagement-45 </a> concerns , which concern the appropriate level of granularity of the media type mechanism.

3.4. 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. For instance, examples that have been 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 specification. 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 TAG finding " Client handling of MIME headers " discusses in more detail the handling of this type of inconsistency.

3.5. 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 [ RFC2616 ] 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 link URI that, when followed, followed as part of a hypertext link, subscribes a user to a mailing list. Remember that search engines may follow such hypertext 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

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 .

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

3.7. Future Directions for Interaction

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

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

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. Increasingly, internationalized textual data formats refer to the Unicode repertoire [ UNICODE ] for character definitions.

Text (i.e., a sequence of characters from a repertoire) is distinct from serving data with a media type beginning with "text/". Although XML-based formats are textual, many 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.

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.

deleted text: <strong> Note: </strong> Text (i.e., a sequence of characters from a repertoire) is distinct from serving data with a media type beginning with "text/". Although XML-based formats are textual, many XML-based formats do not consist primarily of phrases in natural language. See the section on <a href="#xml-media-types" shape="rect"> media types for XML </a> for issues that arise when "text/" is used in conjunction with an XML-based format. </p> <p> See TAG issue <a href="http://www.w3.org/2001/tag/ilist#binaryXML-30" shape="rect"> binaryXML-30 .

4.2. Versioning and Extensibility

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

For more information about versioning strategies and agent behavior in the face of unrecognized extensions, see See TAG issue XMLVersioning-41 </a> , which concerns good practices for designing extensible XML languages and for handling versioning. See also "Web Architecture: Extensible Languages" [ EXTLANG ].

4.3. Separation of Content, Presentation, and Interaction

The Web is a heterogeneous environment where a wide variety of agents provide access to content to users with a wide variety of capabilities. It is good practice for authors to create content that can reach the widest possible audience, including users with graphical desktop computers, hand-held devices and 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; his follows from the principle of orthogonal specifications . 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: recombination on the server allows the server to send out generally smaller amounts of data that can be tailored to specific devices (such as mobile phones). However, such data will not be readily reusable by other clients and may not allow client-side agents to perform useful tasks unanticipated by the author. When a client does the work of recombination, content is likely to be more reusable by a broader audience and more robust. However, such data may be of greater size and may require more computation by the client.

Of course, it may not always be desirable to reach the widest possible audience. Designers should consider appropriate technologies for limiting the audience. For instance digital signature technology, access control , and other technologies are appropriate for controlling access to content.

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

See the TAG issues <a href="http://www.w3.org/2001/tag/ilist#formattingProperties-19" shape="rect"> formattingProperties-19 (concerning interoperability in the case of formatting properties and <a href="http://www.w3.org/2001/tag/ilist#contentPresentation-26" shape="rect"> names) and contentPresentation-26 </a>. (concerning the separation of semantic and presentational markup).

4.4. 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 birth of the hypertext Web as we know it today.

When one resource (representation) refers to another resource with a URI, this constitutes a link between the two resources. Additional metadata may also form part of the link (see [ XLink10 ], for example). 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 links among representations.

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

4.5. XML-Based Data Formats

Many data formats are XML-based , that is to say they conform to the syntax rules defined in the XML specification [XML10] . This section discusses issues that are specific to such formats. Anyone seeking guidance in this area is urged to consult the "Guidelines For the Use of XML in IETF Protocols" [IETFXML] , which contains a thorough discussion of the considerations that govern whether or not XML ought to be used, as well as specific guidelines on how it ought to be used. While it is directed at Internet applications with specific reference to protocols, the discussion is generally applicable to Web scenarios as well.

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

4.6. Data Formats Used to Build New Information Space Applications

Because of their role in defining fragment identifier semantics, 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 [ RDF10 ]. This document does not discuss the Semantic Web in detail; the TAG expects that future editions of this document will. See the related TAG issue <a href="http://www.w3.org/2001/tag/ilist.html#httpRange-14" shape="rect"> httpRange-14 .

5.1. Orthogonal Specifications </h4>

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

• One identifies a resource with a URI. One may assign and publish then use a URI 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. 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.

Orthogonal abstractions benefit from orthogonal specifications. deleted text: Specifications should clearly indicate those features that simultaneously access information from otherwise orthogonal abstractions. For example a specification should draw attention to a feature that requires information from both the header and the body of a message. </p> <p> Although the HTTP, HTML, and URI specifications are orthogonal for the most part, they are not entirely so. Experience demonstrates that where they are not, problems have arisen:

• The HTML specification — — a data format specification — — includes a protocol extension of sorts: it specifies how a user agent sends HTML form data to a server (as a URI query string). The design works reasonably well, although there are limitations related to internationalization (see the TAG finding " URIs, Addressability, and the use of HTTP GET and POST " ) and the query string design impinges on the server design. 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.
• The HTML specification allows content providers to instruct HTTP servers to build response headers from META element instances. This is an abstraction violation; the software developer community would benefit from being able to find all HTTP headers from the HTTP specification (including any associated extension registries and specification updates per IETF process). Perhaps as a result, this feature of the HTML specification is not widely deployed. Furthermore, this design has led to confusion in user agent development. The HTML specification states that META in conjunction with http-equiv is intended for HTTP servers, but many HTML user agents interpret http-equiv='refresh' as a client-side instruction.
• Some content authors use the META / http-equiv approach to declare the character encoding scheme of an HTML document. By design, this is a hint that an HTTP server should emit a corresponding "Content-Type" header field. In practice, the use of the hint in servers is not widely deployed. Furthermore, many user agents use this information to override the "Content-Type" header sent by the server, violating protocol semantics.

A specification should clearly indicate which features advance into abstraction territory rightfully governed by another specification.

5.2. Extensibility </h4>

The information in the Web and the technologies used to represent that information change over time. Extensibility describes the property of a technology that promotes both evolution and 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. 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 language subset. Languages that exhibit this property are said to be "extensible." Language designers can facilitate extensibility by defining how implementations must handle unknown extensions — — for example, that they be ignored (in some way) or should be considered errors.

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

For further discussion, see the section on versioning and extensibility . See also TAG issue <a href="http://www.w3.org/2001/tag/ilist#xmlProfiles-29" shape="rect"> xmlProfiles-29 .

5.3. Error Handling </h4>

Errors occur in networked information systems. An error condition can be well-specified (e.g., well-formedness errors in XML or 4xx client errors in HTTP) or arise unpredictably. Error correction means that an agent repairs an 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 hardware failure. Error recovery means that an agent does not repair an error condition but continues processing. 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 transparent 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 message 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 <a href="#ext-version" shape="rect"> extensibility and versioning [section 4.2] .
• Error behavior that is appropriate for a person may not be appropriate for software. People are capable of exercising judgement in ways that software applications generally cannot. An informal error response may suffice for a person but not for a processor.

See the TAG issues <a href="http://www.w3.org/2001/tag/ilist#contentTypeOverride-24" shape="rect"> issue contentTypeOverride-24 </a> and <a href="http://www.w3.org/2001/tag/ilist#errorHandling-20" shape="rect"> errorHandling-20 </a>. , which concerns the source of authoritative metadata.

5.4. Protocol-based Interoperability </h4>

The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the syntax, semantics, and sequence 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.

6. 7. References

CGI

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

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 .

deleted text: INFOSET deleted text:

deleted text: deleted text: XML Information Set (Second Edition) </cite> , , J. Cowan, R. Tobin, Editors, W3C Recommendation, 4 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&uumlaut;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.

deleted text: OWL10 deleted text:

deleted text: deleted text: OWL Web Ontology Language Reference </cite> , , G. Schreiber, M. Dean, 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/ .

deleted text: P3P10 deleted text:

deleted text: deleted text: The Platform for Privacy Preferences 1.0 (P3P1.0) Specification </cite> , , 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.

deleted text: RDF10 deleted text:

deleted text: deleted text: Resource Description Framework (RDF) Model and Syntax Specification </cite> , , O. Lassila, R. R. Swick, Editors, W3C Recommendation, 22 February 1999, http://www.w3.org/TR/1999/REC-rdf-syntax-19990222 . Latest version available at http://www.w3.org/TR/REC-rdf-syntax .

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.

RFC2616

IETF RFC 2616: Hypertext Transfer Protocol &mdash; 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

RFC977

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

deleted text: SOAP12 deleted text:

deleted text: deleted text: SOAP Version 1.2 Part 1: Messaging Framework </cite> , , M. Hadley, N. Mendelsohn, J. Moreau, H. Frystyk Nielsen, M. Gudgin, Editors, W3C Recommendation, 24 June 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ . Latest version available at http://www.w3.org/TR/soap12-part1/ .

deleted text: SVG11 deleted text:

deleted text: deleted text: Scalable Vector Graphics (SVG) 1.1 Specification </cite> , , 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.

deleted text: VOICEXML2 deleted text:

deleted text: deleted text: Voice Extensible Markup Language (VoiceXML) Version 2.0 </cite> , , J. Ferrans, A. Hunt, B. Lucas, B. Porter, K. G. Rehor, S. Tryphonas, S. McGlashan, D. C. Burnett, J. Carter, P. Danielsen, 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 .

deleted text: XHTML11 deleted text:

deleted text: deleted text: XHTML™ XHTMLâ„¢ 1.1 - Module-based XHTML </cite> , , M. Altheim, S. McCarron, Editors, W3C Recommendation, 31 May 2001, http://www.w3.org/TR/2001/REC-xhtml11-20010531 . Latest version available at http://www.w3.org/TR/xhtml11/ .

deleted text: XLink10 deleted text:

deleted text: deleted text: XML Linking Language (XLink) Version 1.0 </cite> , , S. J. DeRose, E. Maler, D. Orchard, Editors, W3C Recommendation, 27 June 2001, http://www.w3.org/TR/2001/REC-xlink-20010627/ . Latest version available at http://www.w3.org/TR/xlink/ .

deleted text: XML10 deleted text:

deleted text: deleted text: Extensible Markup Language (XML) 1.0 (Third Edition) </cite> , , F. Yergeau, T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, Editors, W3C Recommendation, 4 February 2004, http://www.w3.org/TR/2004/REC-xml-20040204 . Latest version available at http://www.w3.org/TR/REC-xml .

deleted text: XMLNS deleted text:

deleted text: deleted text: Namespaces in XML 1.1 </cite> , , A. Layman, R. Tobin, T. Bray, D. Hollander, Editors, W3C Recommendation, 4 February 2004, http://www.w3.org/TR/2004/REC-xml-names11-20040204 . Latest version available at http://www.w3.org/TR/xml-names11/ .

deleted text: XMLSCHEMA deleted text:

deleted text: deleted text: XML Schema Part 1: Structures </cite> , , H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn, Editors, W3C Recommendation, 2 May 2001, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ . Latest version available at http://www.w3.org/TR/xmlschema-1/ .

XMPP

The Extensible Messaging and Presence Protocol ( XMPP ) IETF Working Group is developing "an open, XML-based protocol for near real-time extensible messaging and presence. It is the core protocol of the Jabber Instant Messaging and Presence technology..."

deleted text: XPTRFR deleted text:

deleted text: deleted text: XPointer Framework </cite> , , P. Grosso, E. Maler, J. Marsh, N. Walsh, Editors, W3C Recommendation, 25 March 2003, http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ . Latest version available at http://www.w3.org/TR/xptr-framework/ .

deleted text: XSLT10 deleted text:

deleted text: deleted text: XSL Transformations (XSLT) Version 1.0 </cite> , , 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 .