Architecture of the World Wide Web

List of Principles and Good Practice notes Notes

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

Identification and Resources </th> <th> Interaction </th> <th> Representations and Formats </th> </tr> <tr valign="top"> <td>

1. Use URIs
2. Compare URI characters
3. URI Opacity
4. New URI schemes
5. Content negotiation with fragments fragments:
6. Available representations
7. Safe retrieval
8. URI persistence
9. URI ambiguity

</td> <td> <ol> <li> <a href="#understand-rest"> Understand REST </a> </li> </ol> </td> <td>

Interaction

1. Authoritative server metadata
2. Don't guess metadata
3. Understand REST

Representations and Formats

1. Format specification availability
2. Media type registration
3. Specified fragment identifier semantics
4. Error recovery
5. Specify error handling
6. Identify features that peek
7. Format extensibility
8. Format compatibility
9. Compatibility behavior
10. Link mechanisms
11. Web linking
12. URI genericity
13. Use Namespaces
14. QName caution
15. Namespace documents
16. XML and text/*

</td> </tr> </table>

1.1. About this Document

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

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

2.1. Comparing Identifiers

The most straightforward way of establishing that two parties are referring to the same resource is to compare compare, as character strings, the URIs they are using, as character strings. using. In section 6 of [ URI ], deleted text: determination of equivalence or difference of URIs is based on determined by string comparison.

The term "character" refers to URI characters as defined section 2 of [ URI ].

Although it is possible to determine that two URIs are equivalent, it is generally not possible deleted text: by inspection of two URIs to be sure that they two URIs that are not equivalent identify different resources. Applications may apply rules beyond basic string comparison (e.g., for "http" URIs, the authority agent is case-insensitive) to reduce the risk of false negatives and positives. Please refer to section 6.1 of [ URI ] for more information about reducing the risk of false positives negatives and negatives. positives.

Web agents that reach conclusions based on comparisons done through means other than those licensed by relevant specifications take responsibility for any problems that result.

<img class="icon" src="story.png" alt="Architecture Storytime" /> For instance, agents Agents should not assume assume, for example, that " http://weather.example.com/Oaxaca " and " http://weather.example.com/oaxaca " identify the same resource, since none of the specifications involved states that the path part of an "http" URI is case-insensitive.

To help parties know when they are referring to the same resource, it follows that URI producers should be conservative about the number of different URIs they produce for the same resource.

Thus, the parties responsible for weather.example.com have no reason to should not use both " http://weather.example.com/Oaxaca " and " http://weather.example.com/oaxaca " to refer to the same resource; agents will not detect the equivalence relationship by following specifications.

There may be other ways to establish that two parties are identifying the same resource that are not based on string comparison; see the section on future directions for determining that two URIs identify the same resource .

2.2. URI Opacity

Although it is tempting to guess at the nature of a resource by inspection of a URI that identifies it, this is not licensed by specifications; this is called URI opacity .

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

On the section other hand, the "mailto" URI scheme specification states that mail URIs identify Internet mailboxes. That normative specification authorizes people and software to infer that the identified resource is an Internet mailbox, although it doesn't guarantee that the authority who minted the URI is actually using the URI to identify a mailbox.

People and software using a URI assigned outside of their own authority should make as few inferences as possible about the identified resource based on <a shape="rect" href="#retrieve-representation"> retrieving the identifier. The more a representation </a> for piece of software depends on such inferences, the more fragile it becomes to change and the lower its generic utility.

For information about how agents convey information about a resource. resource, see the section on retrieving a representation .

Editor's note : See TAG issue metadataInURI-31 and TAG finding The use of Metadata in URIs . There is a related principle that has not yet been captured: don't restrict (e.g., through specifications) the URI space allotted to resource owners. See TAG issue siteData-26 : Web site metadata improving on robots.txt, w3c/p3p and favicon etc.

2.3. URI Schemes

In the URI " http://weather.example.com/ ", the "http" that appears before the colon (":") is a URI scheme name. Each URI scheme has a normative specification that explains how to assign identifiers within that scheme. The URI syntax is thus a federated and extensible naming system mechanism wherein each scheme's specification may further restrict the syntax and semantics of identifiers within that scheme. Furthermore, the URI scheme specification specifies whether and how an agent can dereference the URI .

Several URI schemes incorporate allow URI addressing of resources in information systems that pre-date the Web into the URI syntax: Web:

• mailto URIs identify ⁷ Internet mailboxes: <br />
  mailto:nobody@example.org
• ftp URIs identify deleted text: ftp files and directories: <br /> directories accessible using the FTP protocol:
  ftp://example.org/aDirectory/aFile
• news URIs identify USENET newsgroups: <br />
  news:comp.infosystems.www
• tel URIs identify terminals on the telephone network: <br />
  tel:+1-816-555-1212

Other URI schemes have been introduced since the advent of the Web, including those introduced as a consequence of new protocols. Examples of such URI schemes include:

• http URIs: <br />
  http://www.example.org/something?with=arg1;and=arg2
• ldap URIs: <br />
  ldap://ldap.itd.umich.edu/c=GB?objectClass?one ldap://ldap.example.org/c=GB?objectClass?one
• URNs: <br />
  urn:oasis:SAML:1.0

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

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

deleted text: <img class="icon" src="story.png" alt="Architecture Storytime" /> Consider our travel scenario : should the authority providing information about the weather in Oaxaca register a new URI scheme "weather" for the identification of resources related to the weather? They might then publish URIs such as " weather://travel.example.com/oaxaca ". While the Web architecture allows the definition of new schemes, there is a cost to registration and especially deployment of new schemes. When a an agent dereferences such a URI, if what really happens is that HTTP GET is invoked to retrieve an HTML representation of the resource, then an "http" URI would have sufficed. If a URI scheme exists that meets the needs of an application, designers should use it rather than invent one. Furthermore, designers should expect that it will prove useful to be able to share a URI across applications, even if that utility is not initially evident.

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

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

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

2.4. Fragment Identifiers

2.5. Using a URI to Access a Resource

To dereference a URI means to access the resource identified by the URI. Access may take many forms, including retrieving a representation (e.g., using HTTP GET or HEAD), modifying the state of the resource (e.g., using HTTP POST or PUT), and deleting the resource (e.g., using HTTP DELETE).

When accessing a resource, an agent applies relevant specifications in succession, beginning with the specification of the context in which the URI is found (e.g., a format or protocol specification, or an application). Any one of these specifications may define more than one access mechanism (e.g., the HTTP protocol defines a number of access methods , including GET, HEAD, and POST). Note that the information governing the choice of access mechanism may be found in the context, not the URI itself (e.g., the choice of HTTP GET v. HTTP HEAD). The TAG finding " URIs, Addressability, and the use of HTTP GET and POST." discusses issues surrounding multiple access mechanisms and the relation to URI addressability.

Some URI schemes (e.g., the URN scheme [ RFC 2141 ]) do not define dereference mechanisms.

See related TAG issue metadataInURI-31 : Should metadata (e.g., versioning information) be encoded in URIs?

2.6. URI Persistence and Ambiguity

The value of a URI increases with the predictability of interactions using that URI.

Service breakdowns include:

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

There are strong social expectations that once a URI identifies a particular resource, it should continue indefinitely to refer to that resource; this is called URI persistence . URI persistence is always a matter of policy and commitment on the part of authorities servicing URIs. The choice of a particular URI scheme provides no guarantee that those URIs will be persistent, nor persistent or that they will not be persistent.

URI ambiguity refers to the use of the same URI to refer to more than one distinct thing.

Ambiguous use of a URI can be costly. Suppose that one division of Example, Inc. maintains data about company Web pages, including who created them and when. Another division in the company maintains data about companies, including who created them and when. The second data set uses the URIs of the organization's home page to identify the organization itself. When the two data sets are merged, the reuse of the URI causes information about companies to be merged with that of the home pages, resulting in potentially costly nonsense.

Ambiguity, Ambiguity is an error, error and should not be confused with indirect identification, which is common. One indirectly identifies things though related things, such as people by their mailboxes, and organizations by their Web pages. For example, when conference organizers ask meeting participants to register by giving their email addreses, addresses, both parties know that they are using the mailbox identifier to indirectly identify the person. In terms of Web architecture, " mailto:joe@example.com " still identifies a mailbox, not a person.

The statement "' http://www.example.com/moby ' identifies 'Moby Dick'" is a source of ambiguity since one could understand the statement to refer to very distinct resources: a particular printing of this work, or the work itself in an abstract sense, or the fictional white whale, or a particular copy of the book on the shelves of a library (via the Web interface of the library's online catalog), or the record in the library's electronic catalog which contains the metadata about the work, or the Gutenberg project's online version .

HTTP [ RFC2616 ] has been designed to help service URIs. For example, HTTP redirection (via some of the 3xx response codes) permits servers to tell a user agent that further action needs to be taken by the user agent in order to fulfill the request (e.g., the resource has been assigned a new URI). In addition, content negotiation also promotes consistency, as a site manager would is not deleted text: be required to define new URIs when adding support for each a new format specification that is supported, as would be the case with protocols specification. Protocols that don't do not support content negotiation, such as FTP. negotiation (e.g., FTP) require a new identifier when a new format is introduced.

For more discussion about URI persistence, refer to [ Cool ]. ^{<a name="note9" id="note9" href="#note-cool-uri-title"> 9 10}

2.7. Access Control

As we have seen, identification of a resource is distinct from interaction with that resource. It is reasonable to limit access to the resource (e.g., for security reasons), but it is unreasonable to prohibit others from merely identifying the resource.

As an analogy: A building might have a policy that the public may only enter via the main front door, and only during business hours. People employed in the building and in making deliveries to it might use other doors as appropriate. Such a policy would be enforced by a combination of security personnel and mechanical devices such as locks and pass-cards. One would not enforce this policy by hiding some of the building entrances, nor by requesting legislation requiring the use of the front door and forbidding anyone to reveal the fact that there are other doors to the building.

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

2.8. Future Directions for Identifiers

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

3.1. Messages in the Travel Scenario

The link to the satellite image is an HTML link encoded as <a href="http://example.com/satimage/oaxaca">satellite image</a> . Nadia's browser analyzes the URI and determines that its scheme is "http". The browser opens a network connection to port 80 on the server at "example.com" and sends a "GET" message as specified by the HTTP protocol, requesting a representation of the resource identified by "/satimage/oaxaca".

The server sends a response message to the browser, once again according to the HTTP protocol. The message consists of several headers and a JPEG image. deleted text: Some of the headers (e.g., 'Transfer-encoding') comprise the message metadata.

The browser reads the headers, learns from the 'Content-Type' field that the Internet Media Type of the representation data is text/jpeg image/jpeg , reads the sequence of octets that comprises the representation data, and renders the image.

As described by the HTML specification, the message data consists of a set of name/value pairs corresponding to the HTML form fields. Note that this is not a safe interaction since ; Nadia wishes to change the state of the system by exchanging money for airline tickets.

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

3.2. <a shape="rect" name="rest-model" id="rest-model"> The Representational State Transfer (REST) Model Authoritative Representation Metadata

Successful communication between two parties using a piece of protocols SHOULD invest time in information relies on shared understanding of the REST model and consider the role to which meaning of its principles could guide their design: <ul> <li> statelessness </li> <li> clear assignment the information. Thousands of roles to independent parties </li> <li> uniform address space </li> <li> limited, uniform set of verbs </li> </ul> </div> </div> <div class="section"> <h3> 3.3. Moved here from other sections temporarily </h3> <ul> <li> Introduce notions of client and server? Relation of client to agent can identify and user agent. Relation of server to resource owner. </li> <li> Don't invent communicate about a new protocol when one exists that gets the job done. You'd have to replicate the caching structure, and Web resource. To give these parties the social behavior. Also, you confidence that they are likely to make all talking about the same mistakes made thing when they refer to "the resource identified by the original protocol designers. </li> <li> When you create a new protocol, you may want to create a new following URI scheme ..." the design choice for the Web is, in general, that deleted text: corresponds to it. </li> </ul> </div> </div> <div class="section"> <h2> 4. <a shape="rect" id="representation" name="representation"> Representations and Formats </a> </h2> <p> The <a name="def-representation" id="def-representation"> <dfn> representation </dfn> </a> of the state owner of a resource is an octet sequence consisting of: </p> <ol> <li> <a name="representation-data" id="representation-data"> <dfn> Representation data </dfn> </a>: Electronic data expressed in one or more <a name="data-format" id="data-format"> <dfn> data formats </dfn> </a> used separately or in combination. A data format (e.g., XHTML, CSS, PNG, XLink, RDF/XML, and SMIL animation) is defined by a <a name="format-specification" id="format-specification"> <dfn> format specification </dfn> </a>. A format specification governs assigns the authoritative interpretation of representations of the resource. See the TAG finding " Client handling of <a shape="rect" href="#fragid"> fragment identifiers </a>. </li> <li> <a shape="rect" href="#representation-metadata"> Representation metadata MIME headers" </li> </ol> for related discussion. See also TAG issue rdfURIMeaning-39 .

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

1. Whether the authority responsible for "weather.example.com" responds to build requests at all;
2. Whether the authority responsible for "weather.example.com" makes available one or more representations deleted text: was HTML. Since then, data formats for the Web have flourished. The Web architecture does not constrain which data formats can be used resource identified by " http://weather.example.com/oaxaca ";
3. Whether Nadia has access privileges to build representations. This flexibility is important, since there is continuing progress in such a representation;
4. If the development of new data formats authority responsible for new applications "weather.example.com" has provided more than one representation (in different formats such as HTML, PNG, or RDF, in different languages such as English and Spanish, etc.), the refinement of existing ones. </p> <p> Some characteristics of a data format make it easier to integrate into resulting representation may depend on negotiation between the deleted text: Web architecture. We examine some of those characteristics below. This document does not address generally beneficial characteristics of a specification such as readability, simplicity, attention to programmer goals, attention to user needs, accessibility, internationalization, etc. The section on <a shape="rect" href="#archspecs"> architectural specifications </a> includes references to additional format specification guidelines. </p> agent and server that occurs as part of the HTTP transaction.
5. When Nadia made the request. Since the weather in Oaxaca changes, Nadia should expect that representations will change over time.

3.3. The Representational State Transfer (REST) Model

3.4. Moved here from other sections temporarily

• Introduce notions of client and server? Relation of client to agent and user agent. Relation of server to resource owner.

4.2. 4.1. Interoperability and the Use of Standard Format Specifications

For a data format to be usefully interoperable between two parties, the parties must have a shared understanding of its syntax and semantics. This is not to imply that a sender of data can count on constraining its treatment by a receiver; simply that making good use of electronic data usually requires knowledge of its designers' intentions.

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

Although the Web architecture allows for the deployment of new data formats, the creation and deployment of new formats (and agents able to handle them) are is very expensive. Thus, before inventing a new data format, designers should carefully consider re-using one that is already available. For example, if a format is required to contain human-readable text with embedded hyperlinks, it is almost certainly better to use HTML for this purpose than to invent a new format.

4.3. 4.2. Error Handling

Errors, of course, Errors occur in the deployment of software and data. The degree to which errors are tolerated varies depends on application context. User agents act on behalf of the user and therefore are expected to help the user understand the nature of errors, and possibly overcome them. User agents that correct errors without the consent of the user are not acting on the user's behalf.

To promote interoperability, specifications should set expectations about behavior in the face of known error conditions.

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

4.4. 4.3. Information Hiding

When designing specifications that address independent functions of a system, references normative dependencies between the specifications are, in general, harmful since such references dependencies impede the independent evolution of the specifications.

For example, it is a strength of XML that XPath cannot query the HTTP header. It is a strength of HTTP that it does not refer to details of the underlying TCP to the extent that it cannot be run over a different transport service. Similarly, the RDF data graph has a significance that is independent of the actual serialization.

Sometimes it is necessary (and even good for given application) to cross specification boundaries. For example, it is good for an HTTP agent to be aware of TCP speeds and round trip times to different mirror servers in order to optimize the choice of server.

4.5. 4.4. Binary and Textual Data Formats

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

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

In principle, all data can be represented using textual formats.

The trade-offs between binary and textual data formats are complex and application-dependent. Binary formats can be substantially more compact, particularly for complex pointer-rich data structures. Also, they can be consumed more rapidly by agents in those cases where they can be loaded into memory and used with little or no conversion.

Textual formats are often more portable and interoperable, since there are fewer choices for representation of the basic units (characters), and those choices are well-understood and widely implemented.

Textual formats also have the considerable advantage that they can be directly read and understood by human beings. This can simplify the tasks of creating and maintaining processing software, and allow the direct intervention of humans in the processing chain without recourse to tools any more complex than the ubiquitous text editor. Finally, it simplifies the necessary human task of learning about new data formats (the "View Source" effect).

It is important to emphasize that intuition as to such matters as data size and processing speed are not a reliable guide in data format design; quantitative studies are essential to a correct understanding of the trade-offs.

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

4.6. 4.5. Extensibility and Versioning

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

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

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

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

Compatible formats

Format version M is compatible with format version N if agents designed to process all instances of M can also process all instances of N. The compatibility relationship is not always symmetric.

Forwards compatibility

Format version M is forwards compatible with respect to format version N if M is compatible with N and M predates N.

Backwards compatibility

Format version M is backwards compatible with respect to format version N if M is compatible with N and N predates M.

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

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

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

4.7. 4.6. Composition of Data Formats

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

Toward the shallow end of the spectrum, it is possible to embed text comments in some image formats, such as JPEG/JFIF. Although these comments are embedded in the containing data, they have little or no effect on the content of the image.

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

Near the middle of the spectrum, there are container formats such as SOAP which fully expect to be composed from multiple namespaces but which provide an overall semantic relationship of message envelope and payload.

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

Composition is related to but distinct from the question of whether a data format is intended as a final form . For example, one can imagine embedding SVG in a JPEG image thus combining final-form and reusable agents, data, whereas a SOAP envelope might provide nothing more than a container for a particular payload that has no presentation final form at all.

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

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

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

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

4.8. 4.7. Presentation, Content, and Interaction

Replacement text from C. Lilley expected.

In many cases, the information encoded in a data format is logically separable from the choice of ways in which it may be presented to a human, and the modes of interaction it may support.

While such separation is, where possible, often advantageous, it is clearly not always possible and in some cases not desirable either.

See also TAG issues Issue formattingProperties-19 and contentPresentation-26 .

4.9. 4.8. Hyperlinks

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

Simple, There are linking paradigms that are more powerful than HTML's single-ended, single-direction, inline links are not the most powerful linking paradigm imaginable. They hyperlinks. But HTML-style hyperlinks are deleted text: very easy to understand, deleted text: however, and they can be authored by individuals (or other agents) that have no control or write access to the other end point.

See also the section on hyperlinks in XML .

4.10. 4.9. XML-Based Data Formats

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

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

4.11. 4.10. Future Directions for Representations and Formats

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

5.1. Principles, Constraints, etc.

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

The important points of this document are categorized as follows:

Constraint

An architectural constraint is a restriction in behavior or interaction within the system. Constraints may be imposed for technical, policy, or other reasons.

Design Choice

In the design of the Web, some design choices, like the names of the <p> and <li> elements in HTML, or the choice of the colon character in URIs, are somewhat arbitrary; if <par>, <elt>, or * had been chosen instead, the large-scale result would, most likely, have been the same. Other design choices are more fundamental; these are the focus of this document.

Good practice

Good practice -- — by software developers, content authors, site managers, users, and specification writers -- — increases the value of the Web.

Principle

An architectural principle is a fundamental law rule that applies to a large number of situations and variables. Architectural principles include "separation of concerns", "generic interface", "self-descriptive syntax," "visible semantics," "network effect" (Metcalfe's Law), and Amdahl's Law: "The speed of a system is determined by its slowest component."

Property

Architectural properties include both the functional properties achieved by the system, such as accessibility and global scope, and non-functional properties, such as relative ease of evolution, re-usability of components, efficiency, and dynamic extensibility.

7.1. Normative References

Editor's note : The usage of a normative reference in this document needs clarification.

IANASchemes

IANA's online registry of URI Schemes is available at http://www.iana.org/assignments/uri-schemes.

Dan Connolly's list of URI schemes is a useful resource for finding out which references define various URI schemes.

MEDIATYPEREG

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

RFC2045

IETF " RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies ", N. Freed, N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2045.txt.

RFC2046

IETF " RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ", N. Freed, N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2046.txt.

RFC2119

IETF " RFC 2119: Key words for use in RFCs to Indicate Requirement Levels ", S. Bradner, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.

URI

"Uniform Resource Identifiers (URI): Generic Syntax" (T. Berners-Lee, R. Fielding, L. Masinter, Eds.) is currently being revised. The IETF Internet Draft draft-fielding-uri-rfc2396bis-03 is expected to obsolete RFC 2396 , which is the current URI standard. "Architecture of the World Wide Web" uses the concepts and terms defined in draft-fielding-uri-rfc2396bis-03, preferring them to those defined in RFC 2396. The TAG is tracking the evolution of draft-fielding-uri-rfc2396bis-03.

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.

7.2. Architectural Specifications

ATAG10

"Authoring Tool Accessibility Guidelines 1.0," J. Treviranus, C. McCathieNevile, I. Jacobs, and J. Richards, eds., 3 February 2000. This W3C Recommendation is http://www.w3.org/TR/2000/REC-ATAG10-20000203/.

CHARMOD

"Character Model for the World Wide Web," M. Dürst and F. Yergeau, eds., 30 April 2002. This W3C Working Draft is http://www.w3.org/TR/2002/WD-charmod-20020430/. The latest version is available at http://www.w3.org/TR/charmod/.

DIPRINCIPLES

"Device Independent Principles," R. Gimson, Ed., 18 September 2001. This W3C Working Draft is http://www.w3.org/TR/2001/WD-di-princ-20010918/. The latest version is available at http://www.w3.org/TR/di-princ/.

Fielding

" Principled Design of the Modern Web Architecture ", R.T. Fielding and R.N. Taylor, UC Irvine. In Proceedings of the 2000 International Conference on Software Engineering (ICSE 2000), Limerick, Ireland, June 2000, pp. 407-416. This document is available at http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf.

RFC1958

IETF " RFC 1958: Architectural Principles of the Internet ", B. Carpenter, June 1996. Available at http://www.ietf.org/rfc/rfc1958.txt.

QA

"QA Framework: Specification Guidelines," D. Hazaël-Massieux, L. Henderson, L. Rosenthal, D. Dimitriadis, K. Gavrylyuk, eds., 10 February 2003.This W3C Working Draft is http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/. The latest version is available at http://www.w3.org/TR/qaframe-spec/.

UAAG10

"User Agent Accessibility Guidelines 1.0," I. Jacobs, J. Gunderson, E. Hansen, eds., 17 December 2002. This W3C Recommendation is http://www.w3.org/TR/2002/REC-UAAG10-20021217/.

WCAG10

"Web Content Accessibility Guidelines 1.0," W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 5 May 1999. This W3C Recommendation is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.

WSA

"Web Services Architecture," D. Booth, M. Champion, C. Ferris, F. McCabe, E. Newcomer, D. Orchard eds., 14 May 2003. This W3C Working Draft is http://www.w3.org/TR/2003/WD-ws-arch-20030514/. The latest version of this document is available at http://www.w3.org/TR/ws-arch/.

XAG

" XML Accessibility Guidelines ", D. Dardailler, S. Palmer, C. McCathieNevile, 3 October 2002. This W3C Working Draft is http://www.w3.org/TR/2002/WD-xag-20021003. The latest version is available at http://www.w3.org/TR/xag.

7.3. Non-Normative References

Cool

" Cool URIs don't change " T. Berners-Lee, W3C, 1998 Available at http://www.w3.org/Provider/Style/URI.

DAMLOIL

" DAML+OIL (March 2001) Reference Description ", D. Connolly, F. van Harmelen, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, 18 Dec 2001. This W3C Note is available at http://www.w3.org/TR/2001/NOTE-daml+oil-reference-20011218.

EXTLANG

" Web Architecture: Extensible Languages , T. Berners-Lee, D. Connolly, 10 February 1998. This W3C Note is available at http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210.

Eng90

" Knowledge-Domain Interoperability and an Open Hyperdocument System ", D. C. Engelbart, June 1990.

Dan Connolly's list of URI schemes is a useful resource for finding out which references define various URI schemes.

IETFXML

IETF " Guidelines For The Use of XML in IETF Protocols ," S. Hollenbeck, M. Rose, L. Masinter, eds., 2 November 2002. This IETF Internet Draft is available at http://www.imc.org/ietf-xml-use/xml-guidelines-07.txt. If this document is no longer available, refer to the ietf-xml-use mailing list .

IRI

IETF " Internationalized Resource Identifiers (IRIs)" , M. Duerst, M. Suignard, Nov 2002. This IETF Internet Draft is available at http://www.w3.org/International/iri-edit/draft-duerst-iri.html. If this document is no longer available, refer to the home page for Editing 'Internationalized Resource Identifiers (IRIs)' .

OWL10

" Web Ontology Language (OWL) Reference Version 1.0 ", M. Dean, D. Connolly, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, L. A. Stein, eds., 12 Nov 2002. This W3C Working Draft is available at http://www.w3.org/TR/2002/WD-owl-ref-20021112/.

P3P10

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

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.

RDF10

" Resource Description Framework (RDF) Model and Syntax Specification ", O. Lassila, R. R. Swick, eds., 22 February 1999. This W3C Recommendation is available at http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.

REST

" Representational State Transfer (REST) ", Chapter 5 of "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Thesis of R. T. Fielding, 2000. Available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.

RFC2141

IETF " RFC 2141: URN Syntax ", R. Moats, May 1997. Available at http://www.ietf.org/rfc/rfc2141.txt.

RFC2718

IETF " Guidelines for new URL Schemes ", L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, November 1999. Available at: http://www.ietf.org/rfc/rfc2718.txt.

RFC3023

IETF " RFC 3023: XML Media Types ", M. Murata, S. St. Laurent, D. Kohn, January 2001. Available at: http://www.rfc-editor.org/rfc/rfc3023.txt

RFC3236

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

RFC3401

IETF " RFC 3401: Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS ", M. Mealing, October 2002. Available at: http://www.rfc-editor.org/rfc/rfc3401.txt

SOAP12

" SOAP Version 1.2 Part 1: Messaging Framework ", M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, H. Frystyk Nielsen, eds., 24 June 2003. This W3C Recommendation is available at http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.

SVG10

" Scalable Vector Graphics (SVG) 1.1 Specification ", J. Ferraiolo, Fujisawa Jun, D. Jackson, eds., 14 January 2003. This W3C Recommendation is available at http://www.w3.org/TR/2003/REC-SVG11-20030114/.

UNICODE

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

UniqueDNS

" IAB Technical Comment on the Unique DNS Root" , B. Carpenter, 27 September 1999. Available at http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm.

XHTML10

" XHTML 1.0: The Extensible HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0 ", S. Pemberton et al., 26 January 2000, revised 1 August 2002. Available at http://www.w3.org/TR/2002/REC-xhtml1-20020801/.

XLink10

" XML Linking Language (XLink) Version 1.0 ", S. DeRose, E. Maler, D. Orchard, 27 June 2001. This W3C Recommendation is available at http://www.w3.org/TR/2001/REC-xlink-20010627/.

XML10

" Extensible Markup Language (XML) 1.0 (Second Edition) ", T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler, 6 October 2000. This W3C Recommendation is available at http://www.w3.org/TR/2000/REC-xml-20001006.

XMLNS

" Namespaces in XML ", T. Bray, D. Hollander, A. Layman, 14 Jan 1999. This W3C Recommendation is available at http://www.w3.org/TR/1999/REC-xml-names-19990114/.

XPTRFR

" XPointer Framework ", P. Grosso, E. Maler, J. Marsh, N. Walsh, eds., 25 March 2003. This W3C Recommendation is available at http://www.w3.org/TR/2003/REC-xptr-framework-20030325/.