Architecture of the World Wide Web

1.1. About this Document

The intended audience for this document includes: </p> <ol> <li> Participants in W3C Activities, i.e., developers Architecture defines the desired operational behavior of Web components within the system, including software, machine, and human components, and protocols for interactions between components. The Web architecture is influenced by social requirements and software engineering principles, leading to design choices that constrain the behavior of the Web in order for the system to achieve desired properties. 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 common straightforward way to establish of establishing that two parties are identifying referring to the same resource is to compare the spelling (i.e., as strings) of the identifiers the parties URIs they are using. Section using, as character strings. In section 6 of [ URI ] discusses this type of analysis. In that specification, ], determination of equivalence or difference of URIs is based on string comparison, perhaps augmented by reference to additional rules provided by comparison.

Good practice

URI scheme definitions (e.g., for HTTP URIs, the authority component is case-insensitive). Depending on the application, an agent may invest more processing effort characters: If a URI has been assigned to deleted text: reduce the likelihood of a deleted text: false negative (i.e., two URIs identify the same resource, but that was not detected). </p> <p> There may be other ways Web components SHOULD refer to deleted text: establish that two parties are identifying the deleted text: same resource that are not based on string comparison; see the section on future directions for <a shape="rect" href="#future-comparison"> determining that two URIs identify using the same resource </a>. URI, character for character.

<span class="ednote"> Editor's note </span>: Dan Connolly has suggested the The term "coreference" instead "character" refers to URI characters as defined section 2 of "equivalence" [ URI ].

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

Agents Web components that reach conclusions about identity beyond what they are based on comparisons done through means other than those licensed deleted text: to do (e.g., by specification, or community convention, or site-specific convention) relevant specifications take responsibility for any problems that result. For instance, agents components should not assume 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 "http" URI is case-insensitive. deleted text: Web servers may vary in how they are configured to handle case-sensitivity. Agents that assume these URIs identify the same resource take responsibility for any resulting problems. </p> <p> Although it is possible to determine that two URIs are equivalent, it is generally not possible by mere inspection of two URIs to be sure that they identify different resources. Web architecture does not constrain resources to be uniquely named. </p> <p class="prefix"> Good practice </p> <p class="practice"> <a shape="rect" name="lc-uri-scheme" id="lc-uri-scheme"> Spelling URIs: </a> If an agent has been provided with a URI to refer to a resource, the agent SHOULD use the spelling of the URI as it was originally provided.

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. For instance, the parties responsible for weather.example.com have no reason to use both " http://weather.example.com/Oaxaca " and " http://weather.example.com/oaxaca " to refer to the same resource; agents components will not detect the equivalence relationship. In this case, one URI should be chosen and used consistently. See section 6.3 of [ <a shape="rect" href="#URI"> URI </a> ] for further advice on how to reduce the risk of false negatives. relationship by following specifications.

URI consumers cannot, in general, determine There may be other ways to establish that two parties are identifying the meaning of a same resource deleted text: by inspection of a URI that identifies it. 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 . In our travel scenario , the example URI ( (" http://weather.example.com/oaxaca ) ") suggests that the identified resource has something to do with the weather in Oaxaca. deleted text: Although short, meaningful URIs benefit people, URI consumers must not rely on the URI string to communicate the meaning of a resource. A site reporting the weather in Oaxaca could just as easily be identified by the URI " http://vjc.example.com/315 </code>. ". And the URI " http://weather.example.com/vancouver " might identify the resource "my photo album." See the section on retrieving a representation for information about how agents components convey information about a resource.

The more resource metadata is included in a URI, the more fragile the URI becomes (e.g., sensitive to changes in representation).

Editor's note : When finding available on URI opacity, link from here. See TAG issue metadataInURI-31 . 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 siteDate-26 : Web site metadata improving on robots.txt, w3c/p3p and favicon etc.

2.2. 2.3. URI Schemes

In the URI " http://weather.example.com/ </code>, ", the "http" that appears before the colon (":") is a URI scheme name. There are other scheme names, such as "mailto" and "ftp". It is common The name refers to deleted text: classify URIs by scheme; a URI with scheme "http" is called an "HTTP URI." </p> <p> Each URI begins with a deleted text: <a name="def-URI-scheme" id="def-URI-scheme"> <dfn> URI scheme </dfn> </a> name. The scheme name corresponds specification, which explains how to a specification for assigning assign identifiers within that scheme. As such, the The URI syntax is thus a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using within that scheme. Furthermore, the URI scheme specification specifies how an agent a component can dereference the URI .

Several URI schemes incorporate identification mechanisms information systems that pre-date the Web into this the URI syntax:

• MAILTO mailto URIs identify ⁷ mailboxes:
  mailto:nobody@example.org
• FTP ftp URIs identify deleted text: identify ftp files and directories:
  ftp://example.org/aDirectory/aFile
• NEWS news URIs identify USENET newsgroups:
  news:comp.infosystems.www
• TEL tel URIs identify terminals on the telephone network:
  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 URIs for these such URI schemes include:

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

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

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 new URI schemes is high. deleted text: We note in passing that even more expensive than introducing a new URI scheme is introducing a new identification mechanism for the Web; this is considered prohibitively expensive.

Good practice

New URI schemes: Authors of specifications SHOULD avoid introducing NOT introduce a new URI schemes scheme when an existing schemes can be used to meet scheme specifies the goals desired properties of the specifications. identifiers and their relation to resources.

Consider our travel scenario : should the authority providing information about the weather in Oaxaca register a new URI scheme "weather" for the identification of resources related to the weather? They might then publish URIs such as " weather://travel.example.com/oaxaca </code>. ". While the Web Architecture architecture allows the definition of new schemes, there is a cost to registration and especially deployment of new schemes. When an agent a component 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 "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 an agent a component to launch a particular application when retrieving a representation, such dispatching can be accomplished at lower expense by registering a new media type Internet Media Type instead. deleted text: Reasons for this include: </p> <ul> <li> The more resource metadata is included in a URI, the more fragile the URI becomes (e.g., sensitive to changes in representation). Designers should choose URI schemes that allow them to keep their options open. </li> <li> At this time, the registration process for new URI schemes is more strict than for the registration of new media types. </li> </ul> <p> <span class="ednote"> Editor's note </span>: When finding available based on Tim Bray's discussion of this topic, link from here.

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.3. <a shape="rect" name="URI-authority" id="URI-authority"> URI Authority 2.4. Fragment Identifiers

In When navigating within the URI XHTML data that Dan receives as a representation of the resource identified by " http://weather.example.com/ </code>, http://weather.example.com/oaxaca ", Dan finds that the string URI " weather.example.com http://weather.example.com/oaxaca#tom (between "//" and " refers to information about tomorrow's weather in Oaxaca. This URI includes the next "/") called fragment identifier "tom" (the string after the authority component. Many URI schemes include "#").

2.5. Dereferencing Using a URI to Access a Resource

Given a URI, To dereference a system may attempt URI means to perform a variety of operations on access the resource, as might be characterized resource identified by deleted text: such words as "access", "update", "replace", or "find attributes". Available operations depend on the formats and protocols that make use of URIs. The URI specification (in [ <a shape="rect" href="#URI"> URI </a> ], section 1.2.2) defines the deleted text: following terms related to interactions through a URI. </p> <dl> <dt> <a name="def-URI-resolution" id="def-URI-resolution"> <dfn> Resolution </dfn> Access may take many forms, including retrieving a representation </dt> <dd> The process (e.g., using HTTP GET or HEAD), modifying the state of determining an access mechanism the resource (e.g., using HTTP POST or PUT), and deleting the appropriate parameters necessary to dereference resource (e.g., using HTTP DELETE).

When accessing a URI; such resolution may require several iterations. </dd> <dt> <a name="def-URI-dereference" id="def-URI-dereference"> <dfn> Dereference </dfn> </a> </dt> <dd> To dereference a URI is to use an access mechanism to perform an action on the URI's resource. </dd> <dt> <a name="def-representation-retrieval" id="def-representation-retrieval"> <dfn> Retrieval </dfn> </a> </dt> <dd> A URI dereference that causes an agent to retrieve resource, a representation of the associated resource. </dd> </dl> <p> During URI resolution, an agent component applies deleted text: in succession a finite set of relevant specifications, 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, 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 deleted text: <strong> draft </strong> 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.

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.

Good practice

URI Persistence: persistence: Parties responsible for a URI SHOULD service that URI predictably and consistently.

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 rather than a constraint imposed by technological means.

URI deleted text: persistence also improves when ambiguity is removed refers to the use of the same URI to refer to more than one distinct thing.

Good practice

URI ambiguity: Avoid URI ambiguity.

Ambiguous use of a URI can be costly. Suppose that one division of Large Company, Inc. maintains data about what 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 as though it was the URI of 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.

URI identifies. ambiguity differs from "indirect identification," which is common. For instance, example, one may identify meeting participants by using their email addresses (e.g., " joe@example.com "). In this case, all parties know that they are using a mailbox identifier to indirectly identify the person. In terms of Web architecture, " mailto:joe@example.com " still identifies a mailbox, not a person.

As another example of URI ambiguity, saying that the URI " http://www.example.com/moby " identifies "Moby Dick" can lead to confusion because this might be interpreted as any one of the following very distinct resources: a particular printing of this work (say, by ISBN), 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 . deleted text: Similarly, one should not use the same URI to refer to a person and to that person's mailbox.

Ambiguous descriptions HTTP [ RFC2616 ] has been designed to help service URIs. For example, HTTP redirection (via some of deleted text: what a URI identifies increase the likelihood that two parties will think the same URI identifies different resources, and thus that the parties will use the URI inconsistently. This can be costly, as in the case of two databases in which the same URI is used inconsistently; merging the two databases might lead to confusion or errors. </p> <p> HTTP [ <a shape="rect" href="#RFC2616"> RFC2616 </a> ] has been designed to help service URIs. For example, HTTP redirection (via some of the 3xx response codes) permits servers to tell an agent 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 not be required to define new URIs for each new format specification that is supported, as would be the case with protocols that don't support content negotiation, such as FTP.

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

2.7. Access Control

As we have seen, identification of a resource is distinct from interacting interaction with that resource. It is reasonable to control 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.

In the travel scenario , imagine that Dan and Norm both subscribe to the <code> weather.example.com </code> "weather.example.com" newsletter. Dan wishes to point out an article of particular interest to Norm, using a URI. The managers of <code> weather.example.com </code> authority responsible for "weather.example.com" can offer Dan and Norm the benefits of URIs (e.g., bookmarking book marking and linking) and still control limit access to the newsletter by to authorized parties. The Web provides several mechanisms to control access to resources, none of which relies on hiding or suppressing URIs for those resources. For more information on identification and access control, please refer to the TAG finding "' " Deep '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

Web components exchange information via messages that are constructed according to a non-exclusive set of messaging protocols (e.g., HTTP, FTP, NNTP, SMTP ¹⁰ , etc.). A message exchanged between Web components is an octet sequence consisting of:

1. Message data : Electronic data such as a resource representation .
2. Message metadata : Metadata about the message, such as the HTTP Server field, information about how message data has been encoded for transfer (e.g., using gzip), or the request method. A message may even include "meta-metadata" (for message-integrity checks).

This section will describe the architectural principles and constraints regarding interactions between components, including such topics as network protocols and interaction styles, along with interactions between the Web as a system and the people that make use of it. This will include the role of architectural styles, such as REST and SOAP, and the impact of meta-architectures, such as Web Services and the Semantic Web.

3.2. The Representational State Transfer (REST) Model

Good practice

3.3. Moved here from other sections temporarily

• Introduce notions of client and server? Relation of client to implement lazy binding agent and user agent. Relation of strings server to data, in order resource owner.
• Don't invent a new protocol when one exists that gets the job done. You'd have to support dynamically configured delegation systems. This system is designed replicate the caching structure, and the social behavior. Also, you are likely to allow resolution of any type of URI, in particular URNs. </p> </div> <div class="section"> <h4> 2.8.5. <a id="non-hier-admin" shape="rect" name="non-hier-admin"> Non-hierarchical administration </a> </h4> <p> One area of work involves make the creation of globally unique identifiers in same mistakes made by the original protocol designers.
• When you create a file-sharing system without centralized or hierarchical administration. </p> </div> new protocol, you may want to create a new URI scheme that corresponds to it.

4.1. Authoritative representation metadata

Successful communication between two parties about a piece of information relies on shared understanding of the meaning of the information. Thousands of independent parties can identify and communicate about a Web resource. To give these parties the confidence that is not part they are all talking about the same thing when they refer to "the resource identified by the following URI ..." the design choice for the Web is, in general, that the owner of a resource assigns the authoritative interpretation of representations of the representation (e.g., the HTTP Server field or resource. See the request method, URI, etc.). A message may even include "meta-metadata" (for message-integrity checks). The representation consists those bits that would not change regardless TAG finding " Client handling of the transfer protocol used to exchange them. MIME headers" for related discussion.

In our deleted text: previous travel scenario </a> , the representation authority responsible for "weather.example.com" has license to create representations of this resource and assign their authoritative interpretation. Which representation(s) Dan receives deleted text: (and whether he receives one at all) depends on a number of factors, including:

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

We discuss these issues in more detail below. </p> <div class="section"> <h3> 3.1. <a shape="rect" id="authoritative-metadata" name="authoritative-metadata"> Authoritative representation metadata </a> </h3> <p> As discussed above, Inconsistencies between the owner of a resource assign URIs for that resource, create representations format of the resource, representation data and assign their authoritative interpretation. This interpretation is described in part by metadata that is part of the representation, notably the Internet media type. At times there may be inconsistencies between assigned representation metadata and what is specified in a format. do occur. Examples deleted text: of inconsistencies between headers and format data that have been observed in practice include:

• The Unicode actual character encoding of a message body (XML document) representation is inconsistent with the deleted text: value of the charset parameter in the message headers. representation metadata.
• The namespace of the root element of a message body (XML document) the representation data is inconsistent with the value of the 'Content-Type' field in HTTP headers.

User agents should detect such inconsistencies but should not resolve them without involving the user (e.g., by securing permission or at least providing notification). (for example, due to security issues).

Principle

Authoritative server metadata: User agents MUST NOT silently ignore authoritative server metadata.

Thus, for example, if the parties responsible for "weather.example.com" mistakenly label the satellite photo of Oaxaca as "image/gif" instead of "image/jpeg", and if Dan's browser detects a problem, Dan's browser must not silently ignore authoritative server metadata. the problem and render the GIF image. Dan's browser can notify Dan of the problem, notify Dan and take corrective action, etc. Of course, user agent designers should not ignore usability issues when handling this type of error; notification may be discreet, and handling may be tuned to meet the user's preferences.

See the deleted text: <strong> draft </strong> TAG finding " Client handling of MIME headers" for more in-depth discussion and examples.

The Web can be used to interchange resource representations in any format. This flexibility is important, since there is continuing progress in Furthermore, server managers help reduce the development risk of new data formats error through careful assignment of representation metadata.

Principle

Don't guess metadata: Server managers MUST ensure that representation metadata is appropriate for new applications each representation.

4.2. Interoperability and the refinement use of existing ones. </p> Standard Format Specifications

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

Good practice

Format specification availability: To promote the interoperability of a Web data format, there SHOULD be a stable, normative specification which for it that is a deleted text: stable and widely available Web resource. </li> <li> The format specification SHOULD have an officially registered Internet media type (see the [ <a shape="rect" href="#IANAMIME"> IANAMIME </a> ] registry). See TAG finding finding <cite> " <a shape="rect" href="http://www.w3.org/2001/tag/2002/0129-mime"> Internet Media Type registration, consistency of use </a>

Good practice

</cite>." </li> <li> The format specification SHOULD define the syntax and semantics of fragment identifiers. </li> <li> The format specification SHOULD allow Web-wide linking, not just internal document linking. </li> <li> The format specification SHOULD allow authors to use URIs without constraining them to a limited set of URI schemes. </li> <li> The Media type registration: A format specification MAY use Qualified Names (QNames) for identifiers in content, but format designers should be aware of SHOULD have an officially registered Internet Media Type (see the limitations and interoperability risks associated with QNames. [ MEDIATYPEREG ] registry).

See deleted text: the TAG finding " <a shape="rect" href="http://www.w3.org/2001/tag/doc/qnameids.html"> Using QNames as Identifiers in Content Internet Media Type registration, consistency of use " " for more information. </li> </ul>

Good practice

Specified fragment identifier semantics: A format specification SHOULD define the syntax and semantics of fragment identifiers.

Although the Web architecture allows for the deployment of new data formats, the creation and deployment of new formats (and software able to handle them) can be 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. </p> <div class="section"> <h4> 3.2.1. <a shape="rect" name="format-characteristics" id="format-characteristics"> Desirable Characteristics of Format Specifications </a> </h4> <p> As noted above, the utility of data formats starts with the availability of a normative specification. Some of the desirable characteristics of a format include: </p> <dl> <dt> Attention to Programmer Needs </dt> <dd> A specification that is written to meet the needs of programmers is more likely to be implemented, and thus more likely to be useful. In particular, the specification SHOULD be in part formal and mathematical, rather than relying exclusively on narrative. </dd> <dt> Attention to Author Needs </dt> <dd> Formats that allow authors to intuitively and efficiently address problems they are trying to solve, that can be readily learned, that are simple to use, and that are interoperable are more likely to be adopted by authors and authoring tool developers. </dd> <dt> Attention to User Needs </dt> <dd> A number of characteristics of a format specification will address the needs of end users, and doing so will create a market for the format. Attention to issues of accessibility, internationalization, and device-independence will tend to make a format specification more flexible. </dd> <dt> Attention to Error-Handling </dt> <dd> Given that representations are generated by humans (either coded directly or mediated by an authoring tool) and then transmitted in than to invent a heterogeneous network, it is inevitable that errors will occur. Specifications new format.

4.3. Error handling

Errors, of data formats SHOULD be clear about behavior course, occur in the presence deployment of errors. It is reasonable software and data. The degree to specify that which errors are tolerated varies depends on application context.

Principle

Error recovery: Silent recovery from error is harmful.

To promote interoperability, specifications should be worked around, or should result set expectations about behavior in the termination face of a transaction or session. It is not acceptable for the known error conditions.

Good practice

Specify error handling: Format specification designers SHOULD specify component behavior in the face of errors to be left unspecified. error conditions.

See the deleted text: <strong> draft </strong> TAG finding " Client handling of MIME headers" for more discussion about error reporting. </dd> <dd> Issue See also TAG issue errorHandling-20 </a> </dd> <dt> .

4.4. Information hiding </dt> <dd>

When designing specifications that address independent functions of a system, references between the specifications are in general deleted text: harmful. They are harmful because they since such references impede the independent evolution of the specifications. </dd> <dd>

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. </dd> <dd>

Sometimes it is necessary (and even good for given application) to break layers. cross specification boundaries. For example, it is good for an HTTP agent component to be aware of TCP speeds and round trip times to different mirror servers in order to optimize the choice of server. deleted text: When designing specification, identify the functionalities that break layers so it is clear when they are being used. </dd> </dl> <p> The section on <a shape="rect" href="#archspecs"> architectural specifications </a> includes references to additional format specification guidelines.

Good practice

</li> </ul> </div> <div class="section"> <h4> 3.2.2. <a shape="rect" name="format-taxonomy" id="format-taxonomy"> Taxonomic Categorization of Data Formats Identify features that peek: </h4> <p> This section discusses important characteristics of data formats which can together be used to describe and understand them. Format specification designers SHOULD clearly identify the features of a format specification that peek across specification boundaries.

4.5. Binary v. and Textual Data Formats </h5>

A textual data format is one in which the data is specified as a linear sequence of characters. HTML, Internet e-mail, and all XML-based languages formats are textual. In modern textual data formats, the characters are usually taken from the Unicode repertoire. 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 software 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).

deleted text: All things being equal (a rare state of affairs) textual formats are generally preferable to binary ones in Web applications. </p> <p> 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. Composition of Data Formats </h5>

Final-form Many modern data formats are not designed to allow modification or uses other than that intended by their designers. An example would be PDF, which is designed to support the presentation of page images on either screen or paper, and is not readily used in any other way. XSL Formatting Objects (XSL-FO) share this characteristic. </p> <p> XHTML, on the other hand, can be format specifications include mechanisms for composition. These mechanisms range from relatively shallow and is put to a variety of uses including direct display (with highly flexible display semantics), processing by network-sensitive Web spiders limited to support search and retrieval operations, and reprocessing into a variety of derivative forms. </p> <p> In general XML-based data formats are more re-usable relatively deep and repurposable than the alternatives, although the example of XSL-FO shows that this is not an absolute. sophisticated.

There are many cases where final-form is an application requirement; representations which embody legally-binding transactions are an obvious example. In such cases, Toward the use shallow end of deleted text: digital signatures may be appropriate to achieve immutability, whether the format spectrum, it is naturally final-form or possible to embed text comments in some XML vocabulary. </p> <p> On the other hand, where image formats, such requirements are not in play, representations that are reusable and repurposable as JPEG/JFIF. Although these comments are embedded in deleted text: general higher in value, particularly in the case where containing data, they have little or no effect on the content of the information's utility may be long-lived. image.

Some data formats are explicitly designed Towards the deep end, it is possible to be used in combination compose XML documents with others, while some are designed for standalone use. An example of elements from a standalone data format is PDF; it variety of namespaces. How these namespaces interact and what effect an element's namespace has on its ancestors, siblings, and descendents is not typically embedded in representations encoded in other formats. always obvious.

At Near the other extreme is SOAP, middle of the spectrum, there are container formats such as SOAP which is designed explicitly fully expect to contain a "payload" in some non-SOAP vocabulary. Another example is SVG, be composed from multiple namespaces but which is designed to provide an overall semantic relationship of message envelope and payload.

These relationships can be included in compound documents, mixed and which may in turn nested arbitrarily. In principle, a SOAP message can contain information encoded in other XML vocabularies. a JPEG image that contains an RDF comment that references a vocabulary of terms for describing the image.

This characteristic Composition is related to, to but distinct from, from the final-form/reusable distinction discussed above. question of whether a data format is intended as a final form . For example, one can deleted text: certainly imagine cases where it is useful for a representation to include data embedding SVG in multiple different formats, but be considered immutable a JPEG image thus combining final-form and display-only. reusable components, whereas a SOAP envelope might provide nothing more than a container for a particular payload that has no presentation 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.7. Extensibility and Versioning </h5>

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

Good practice

Extensibility: Format extensibility: Format designers should create extensible formats.

Versioning is the term for the evolution of languages formats and documents. Versioning is achieved through extensibility mechanisms and language 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 other vocabulary elements, 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, 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 components designed to process all instances of M can also process all instances of N. The compatibility relationship is not always symmetric.

Forwards compatibility

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

Backwards compatibility

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

Good practice

Compatibility: Format compatibility: Format designers SHOULD define extensibility models that allow forwards compatible and backwards compatible changes.

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

Good practice

Compatibility behavior: Format designers SHOULD define expected behavior when agents components designed to process one version of a format encounter a compatible version of the format.

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

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

4.8. Presentation, Content, and Interaction </h4>

Replacement text from C. Lilley expected.

In many cases, the information contained encoded in a separation 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. Hyperlinks deleted text: in Representations </h4>

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

Simple, single-ended, single-direction, inline links are not the most powerful linking paradigm imaginable. But they They are very easy to understand. And understand, however, and they can be authored by individuals (or other agents) components) that have no control or write access to the other end point.

More sophisticated linking mechanisms have been invented for the Web. XPointer allows links to address content that does not have an explicit, named anchor. XLink allows links to have multiple ends and to be expressed either inline or in "link bases" stored external to any or all of the resources identified by the links it contains.

All of the current common linking mechanisms identify resources by URI and optionally identify portions (or views) of a resource with the fragment identifier. reference.

Good practice

Link mechanisms: Format specification designers SHOULD provide mechanisms for identifying links to other resources and to portions of representations (via fragment identifiers). Allow Web-wide linking, not just internal document linking.

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

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

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

Good practice

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

Good practice

QName caution: Format specification designers MAY use Qualified Names (QNames) for identifiers in representation data, but should be aware of the limitations and interoperability risks associated with them.

TAG issue: What is See the scope of using XLink? <a shape="rect" href="http://www.w3.org/2001/tag/ilist#xlinkScope-23"> xlinkScope-23 TAG finding " Using QNames as Identifiers in Content " for more information. See also TAG issues rdfmsQnameUriMapping-6 and qnameAsId-18 .

3.3. <a shape="rect" id="xml-representation" name="xml-representation"> 4.10. XML-Based Representations Data Formats

Many deleted text: resource representations are encoded in using data formats which are based on XML vocabularies. 1.0 [XML10] . This section discusses issues that are specific to such deleted text: data formats. deleted text: </p> <p> Anyone seeking guidance in this area is urged to consult the "Guidelines For The Use of XML in IETF Protocols" [IETFXML] </a> for the use of XML in Internet Protocols. This document , 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 the IETF BCP. [IETFXML] . Refer also to "XML Accessibility Guidelines" [XAG] for help designing XML formats that lower barriers to Web accessibility for people with disabilities.

3.4. 4.11. 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 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, reusability 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.

<a shape="rect" name="IANAMIME" id="IANAMIME"> IANAMIME MEDIATYPEREG

IANA's online registry of MIME types 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 by 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/ 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

deleted text: <a shape="rect" name="Axioms" id="Axioms"> Axioms </a> </dt> <dd> " <a shape="rect" href="http://www.w3.org/DesignIssues/Axioms"> Universal Resource Identifiers - Axioms of Web Architecture </a> ", T. Berners-Lee, living document dated December 1996. Available at http://www.w3.org/DesignIssues/Axioms. </dd> <dt> Cool

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

deleted text: CSS2 </dt> <dd> " <a shape="rect" href="http://www.w3.org/TR/1998/REC-CSS2-19980512/"> Cascading Style Sheets, level 2 </a> ", B. Bos, H. Lie, C. Lilley, I. Jacobs, 12 May 1998. This W3C Recommendation is available at http://www.w3.org/TR/1998/REC-CSS2-19980512/. </dd> <dt> 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.

deleted text: <dt> <a shape="rect" name="Fragments" id="Fragments"> Fragments </a> </dt> <dd> " <a shape="rect" href="http://www.w3.org/DesignIssues/Fragment"> Fragment Identifiers on URIs </a> ", T. Berners-Lee, living document dated April 1997. Available at http://www.w3.org/DesignIssues/Fragment. </dd> <dt> <a shape="rect" name="HTML40" id="HTML40"> HTML40 </a> </dt> <dd> " <a shape="rect" href="http://www.w3.org/TR/1999/REC-html401-19991224/"> HTML 4.01 Specification </a> ", D. Raggett, A. Le Hors, I. Jacobs, 24 December 1999. This W3C Recommendation is available at http://www.w3.org/TR/1999/REC-html401-19991224/. </dd> <dt> <a shape="rect" name="IANAICP1" id="IANAICP1"> IANAICP1 </a> </dt> <dd> IANA's <a shape="rect" href="http://www.icann.org/icp/icp-1.htm"> ICP-1: Internet Domain Name System Structure and Delegation (ccTLD Administration and Delegation) </a> is available at http://www.icann.org/icp/icp-1.htm. </dd>

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., 14 February 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 Sep 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/.

deleted text: <dt> <a shape="rect" name="W3CPROCESS" id="W3CPROCESS"> W3CPROCESS </a> </dt> <dd> " <a shape="rect" href="http://www.w3.org/Consortium/Process-20010719/"> W3C Process Document </a> ", 19 July 2001 Version. Available at http://www.w3.org/Consortium/Process-20010719/. </dd>