Architecture of the World Wide Web, First Edition

1.1.1. Audience of this Document

This document is intended to inform discussions about issues of Web architecture. The intended audience for this document includes:

1. Participants in W3C Activities; i.e., developers designers of Web technologies and specifications in W3C
2. Other groups and individuals developing designing technologies to be integrated into the Web
3. Implementers of W3C specifications
4. Web content authors and publishers

Readers will benefit from familiarity with the Requests for Comments ( RFC ) series from the IETF , some of which define pieces of the architecture discussed in this document.

Note: This document does not distinguish in any formal way the terms "language" and "format." Context determines which term is used. The phrase "specification designer" encompasses language, format, and protocol designers.

1.1.2. Scope of this Document

This document presents the general architecture of the Web. Other groups inside and outside W3C also address specialized aspects of Web architecture, including accessibility, internationalization, device independence, and Web Services. The section on Architectural Specifications includes references.

This document strikes a balance between brevity and precision while including illustrative examples. TAG findings are informational documents that complement the current document by providing more detail about selected topics. This document includes some important material excerpts from the findings. Since the findings evolve independently, this document also includes references to approved TAG findings. For other TAG issues covered by this document but without an approved finding, references are to entries in the TAG issues list .

Many of the examples in this document involve human activity suppose the familiar Web interaction model where a person follows a link via a user agent, the user agent retrieves and presents data, the user follows another link, etc. This document does not discuss in any detail other interaction models such as voice browsing. For instance, when a graphical user agent running on a laptop computer or hand-held device encounters an error, the user agent can report errors directly to the user through visual and audio cues, and present the user with options for resolving the errors. On the other hand, when someone is browsing the Web through voice input and audio-only output, stopping the dialog to wait for user input may reduce usability since it is so easy to "lose one's place" when browsing with only audio-output. This document does not discuss how the principles, constraints, and good practices identified here apply in all interaction contexts.

1.1.3. Principles, Constraints, and Good Practice Notes

The important points of this document are categorized as follows:

<a name="cat-constraint" id="cat-constraint" shape="rect"> Constraint Principle

An architectural constraint principle is a restriction in behavior or interaction within the system. Constraints may be imposed for technical, policy, or other reasons. </dd> <dt> <a name="cat-design" id="cat-design" shape="rect"> Design Choice </a> </dt> <dd> In the design of the Web, some design choices, like the names fundamental rule that applies to a large number of the <p> situations and <li> 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 limited by its slowest component."

Constraint

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 deleted text: <par>, <elt>, or * paragraph had been chosen instead, instead of p or asterisk (*) instead of colon, the large-scale result would, most likely, have been the same. Other design choices are more fundamental; these are the focus of this document. Design choices can lead to constraints, i.e., restrictions in behavior or interaction within the system. Constraints may be imposed for technical, policy, or other reasons to achieve certain properties of 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.

Good practice

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

deleted text: <dt> <a name="cat-principle" id="cat-principle" shape="rect"> Principle </a> </dt> <dd> An architectural principle is a fundamental rule that applies to a large number of situations and variables. Architectural principles include "separation of concerns", "generic interface", "self-descriptive syntax," "visible semantics," "network effect" (Metcalfe's Law), and Amdahl's Law: "The speed of a system is determined by its slowest component." </dd> <dt> <a name="cat-property" id="cat-property" shape="rect"> Property </a> </dt> <dd> 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. </dd>

This categorization is derived from Roy Fielding's work on "Representational State Transfer" [ REST ]. deleted text: Authors of protocol specifications in particular should invest time in understanding the REST model and consider the role to which of its principles could guide their design: statelessness, clear assignment of roles to parties, uniform address space, and a limited, uniform set of verbs.

1.2.1. <a id="orthogonal-specs" name="orthogonal-specs" shape="rect"> Orthogonal Independent Specifications

Identification, interaction, and representation are orthogonal independent (or, "independent", "orthogonal", or "loosely coupled") concepts: an identifier can be assigned

• one identifies a resource with a URI. One may publish and use a URI without knowing what building any representations are available, agents can interact with of the resource or determining whether any deleted text: identifier, and representations can are available.
• a generic URI syntax allows agents to function in many cases without knowing specifics of URI schemes.
• in many cases one may change the representation of a resource without regard disrupting references to the identifiers or interactions that may dereference them. </p> resource.

Orthogonality in Independence of specifications facilitates a flexible design that can evolve over time. The fact, for For example, that the one may refer to an image can be identified using with a URI without needing any information worrying about the representation format chosen to represent the image. This independence has allowed the introduction of deleted text: that image allowed formats such as PNG and SVG without disrupting references to deleted text: evolve independent of the specifications that define image elements. resources.

Orthogonal Independent abstractions deserve orthogonal benefit from independent specifications. Specifications should clearly indicate those features that simultaneously access information from otherwise orthogonal independent abstractions. For example a specification should draw attention to a feature that requires information from both the header and the body of a message.

Although the HTTP, HTML, and URI specifications are orthogonal independent for the most part, they are not completely orthogonal. independent. Experience demonstrates that where they are not orthogonal, not, problems have arisen:

• The HTML specification includes a protocol extension of sorts: it specifies how a user agent sends HTML form data to a server (as a URI query string). The design works reasonably well, although there are limitations related to internationalization (see the TAG finding " URIs, Addressability, and the use of HTTP GET and POST " ) and the query string design impinges on the server design. Developers Software developers (for example, of [ CGI ] applications) might have an easier time finding the specification if it were published separately and then cited from the HTTP, URI, and HTML specifications.
• The HTML specification allows content providers to instruct HTTP servers to build response headers from META element instances. This is an abstraction violation; the software developer community deserves to be would benefit from being able to find all HTTP headers from the HTTP specification (including any associated extension registries and specification updates per IETF process). Perhaps as a result, this feature of the HTML specification is not widely deployed. Furthermore, this design has led to confusion in user agent development. The HTML specification states that META in conjunction with http-equiv is intended for HTTP servers, but many HTML user agents interpret http-equiv='refresh' as a client-side instruction.
• Some content authors use the META / http-equiv approach to declare the character encoding scheme of an HTML document. By design, this is a hint that an HTTP server should emit a corresponding "Content-Type" header field. In practice, the use of the hint in servers is not widely deployed. Furthermore, many user agents use this information to override the "Content-Type" header sent by the server. This works against the principle of authoritative representation metadata .

1.2.2. Extensibility

The information in the Web and the technologies used to represent that information change over time. Some examples of successful technologies designed to allow change while minimizing disruption include:

• the fact that URI schemes are independently specified, specified;
• the use of an open set of Internet media types in mail and HTTP to specify document interpretation, interpretation;
• the separation of the generic XML grammar and the open set of XML namespaces for element and attribute names, names;
• Extensibility extensibility models in Cascading Style Sheets (CSS), XSLT 1.0, and SOAP SOAP;
• user agent plug-ins plug-ins.

The following applies to languages, in particular Below we discuss the specifications property of "extensibility," exhibited by URIs and some data formats, of and message formats, deleted text: and URIs. <strong> Note: </strong> This document does not distinguish in any formal way the terms "format" and "language." Context has determined which term is used. promotes technology evolution and interoperability.

Language subset : one language is a subset (or, "profile") of a second language if any document in the first language is also a valid document in the second language and has the same interpretation in the second language.

Language extension : one language is an extension of a second language if the second is a language subset of the first (thus, the extension is a superset). Clearly, creating an deleted text: extension language extension is better for interoperability than creating an incompatible language.

Ideally, many instances of a superset language can be safely and usefully processed as though they were in the subset language. language subset. Languages that exhibit this property are said to be "extensible." Language designers can facilitate extensibility by defining how implementations must handle unknown extensions -- for example, that they be ignored (in some way) or should be considered errors.

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

For further discussion, see the section on versioning and extensibility . See also TAG issue xmlProfiles-29 .

1.2.3. Error Handling

Errors occur in networked information systems. The manner in which they are dealt with depends on application context. A user agent acts on behalf of the user and therefore is 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.

Consent does not necessarily imply that the receiving agent must interrupt the user and require selection of one option or another. The user may indicate through pre-selected configuration options, modes, or selectable user interface toggles, with appropriate reporting to the user when the agent detects an error.

To promote interoperability, specifications specification designers should set expectations about behavior in the face of known error conditions. Experience has led to the following observations about error-handling approaches.

• Protocol designers should provide enough information about the error condition so that deleted text: a an agent can address the error condition. For instance, an HTTP 404 message ("resource not found") is useful because it allows user agents to present relevant information to users, enabling them to contact the author representation provider in case of the representation that included the (broken) link. </li> <li> Experience with problems.
• Experience with the cost of building a user agent to handle the diverse forms of ill-formed HTML content convinced the authors designers of the XML specification to require that agents fail deleted text: deterministically upon encountering ill-formed content. Because users are unlikely to tolerate such failures, this design choice has pressured all parties into respecting XML's constraints, to the benefit of all.
• An agent that encounters unrecognized content may handle it in a number of ways, including as an error; see also the section on extensibility and versioning .
• Error behavior that is appropriate for a person may not be appropriate for software. People are capable of exercising judgement in ways that software applications generally cannot. An informal error response may suffice for a person but not for a processor.

See the TAG issues contentTypeOverride-24 and errorHandling-20 .

1.2.4. Protocol-based Interoperability

The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the syntax, semantics, and sequence of the messages interchanged. The technology shared among Web agents lasts longer than the agents themselves.

It is common for programmers working with the Web to write code that generates and parses these messages directly. It is less common, but not unusual, for end users to have direct exposure to these messages. This leads It is often desirable to the well-known "view source" effect, whereby provide users with access to format and protocol details: allowing them to " view source ," whereby they may gain expertise in the workings of the deleted text: systems by direct exposure to the underlying protocols. system.

2.1.1. URI aliases Aliases </span> </p> <p class="practice"> Resource owners should not create arbitrarily different

There are many benefits to ensuring that software can determine, by following specifications, that two URIs for refer to the same resource. deleted text: </p> </div> <p> URI producers should be conservative about the number of different URIs they produce for the same resource. resource, especially when software cannot determine the equivalence of those URIs. For example, the parties responsible for weather.example.com should not use both "http://weather.example.com/Oaxaca" and "http://weather.example.com/oaxaca" to refer to the same resource; agents software will not detect the equivalence relationship by following specifications. On

There may, of course, be good reasons for creating similar-looking URIs. For instance, one might reasonably create URIs that begin with "http://www.example.com/tempo" and "http://www.example.com/tiempo" to provide access to resources by users who speak Italian and Spanish.

Likewise, URI consumers should ensure URI consistency. For instance, when transcribing a URI, agents should not gratuitously escape characters. The term "character" refers to URI characters as defined in section 2 of [ URI ].

Applications may apply rules beyond basic string comparison that are licensed by specifications When a URI alias does become common currency, the URI owner should use protocol techniques such as server-side redirects to reduce connect the risk of false negatives and positives. For example, for "http" URIs, the authority component is case-insensitive. Agents that reach conclusions based on comparisons that are not licensed by relevant specifications take responsibility for any problems that result. Agents should not assume, for example, that "http://weather.example.com/Oaxaca" and "http://weather.example.com/oaxaca" identify the same resource, since none of the specifications involved states that two resources. The community benefits when the deleted text: path part of an "http" URI is case-insensitive. </p> <p> See section 6 [ <a href="#URI" shape="rect"> URI </a> ] for more information about comparing URIs and reducing owner supports both the risk of false negatives "unofficial" URI and deleted text: positives. See the section on future directions for approaches other than string comparison that may allow different parties to <a href="#future-comparison" shape="rect"> assert that two URIs identify the same resource </a>. alias.

2.3.1. 2.2.1. URIs in other Roles

In Web architecture, URIs identify resources. Outside the bounds context of Web architecture specifications, URIs can be useful for other purposes, for example, as database keys. For instance, the organizers of a conference might use "mailto:nadia@example.com" to refer to Nadia. While this usage is not licensed by Web architecture specifications, in the context of the conference, all parties may agree to that local policy and understand one another. Certain properties of URIs, such as their potential for global uniqueness, make them appealing as general-purpose identifiers. In the Web architecture, "mailto:nadia@example.com" identifies an Internet mailbox; that is what is licensed by the "mailto" URI scheme specification. The fact that the URI serves other purposes in non-Web contexts does not lead to URI ambiguity. overloading. URI ambiguity overloading arises when a URI is used to identify two different <em> resources within the context of Web </em> resources. protocols and formats.

2.4.1. URI Scheme Registration </h3> <div class="boxedtext"> <p> <span class="storylab"> Story </span> </p> <div class="story">

When navigating within the XHTML data that Nadia receives as The Internet Assigned Numbers Authority ( IANA ) maintains a representation registry [ IANASchemes ] of mappings between URI scheme names and scheme specifications. For instance, the resource identified by "http://weather.example.com/oaxaca", Nadia finds IANA registry indicates that the URI "http://weather.example.com/oaxaca#tom" refers to information about tomorrow's weather "http" scheme is defined in Oaxaca. This [ RFC2616 ]. The process for registering a new URI includes the fragment identifier "tom" (the string after the "#"). scheme is defined in [ RFC2717 ].

The <a name="def-fragid" id="def-fragid"> <dfn> fragment identifier </dfn> </a> use of a unregistered URI allows indirect identification of schemes is discouraged for a <a name="def-secondary-resource" id="def-secondary-resource"> <dfn> secondary resource </dfn> </a> by reference number of reasons:

• There is no generally accepted way to a primary resource and additional information. The secondary resource locate the scheme specification.
• Someone else may be some portion or subset of the primary resource, some view on representations of using the primary resource, or some scheme for other resource. The interpretation purposes.
• One should not expect that general-purpose software will do anything useful with URIs of fragment identifiers this scheme beyond URI comparison; the network effect is discussed in lost.

Note: Some URI scheme specifications (such as the section on <a href="#media-type-fragid" shape="rect"> media types and fragment identifier semantics </a>. "ftp" URI scheme specification) use the term "designate" where the current document uses "identify."

deleted text: See TAG issues <a href="http://www.w3.org/2001/tag/issues.html#abstractComponentRefs-37" shape="rect"> abstractComponentRefs-37 issue siteData-36 and <a href="http://www.w3.org/2001/tag/issues.html#DerivedResources-43" shape="rect"> DerivedResources-43 </a>. is about expropriation of naming authority.

2.7.1. Internationalized Identifiers

The integration of internationalized identifiers (i.e., composed of characters beyond those allowed by [ URI ]) into the Web architecture is an important and open issue. See TAG issue IRIEverywhere-27 for discussion about work going on in this area.

2.7.2. Assertion that Two URIs Identify the Same Resource

Emerging Semantic Web technologies, including the "Web Ontology Language (OWL)" [ OWL10 ], define RDF [ RDF10 ] properties such as sameAs to assert that two URIs identify the same resource or functionalProperty to imply it.

One consequence of this direction is that URIs syntactically different can be used to identify the same resource. This means that multiple parties may create representations of the (same) resource, all available for retrieval using multiple URIs. A URI owner's rights (e.g., to provide authoritative representation metadata) extend only to the representations served for requests given that URI.

Note also that to URIs that are sameAs one another does not mean they are interchangeable. For instance, suppose that two different organizations own the URIs "http://weather.example.org/stations/oaxaca#ws17a" and "http://weather.example.com/rdfdump?region=oaxaca&station=ws17a". The URIs might both identify the same resource, a certain collection of weather-measuring equipment shared by the two organizations. Although the URIs might be declared "owl:sameAs" each other, the two URI owners might provide very different content when the URIs are dereferenced.

3.3.1. Media Types and Fragment Identifier Semantics

Per [ URI ], in order to know the authoritative interpretation of given a deleted text: fragment identifier, one must dereference the URI containing "U#F", and a representation retrieved by dereferencing URI "U" (which is authoritative), the fragment identifier. The Internet Media Type of ( secondary ) resource identified by "U#F" is determined by interpreting "F" according to the retrieved representation specifies specification associated with the authoritative interpretation Internet media type of the fragment identifier. the representation data. Thus, in the case of Dirk and Nadia, the authoritative interpretation depends on of the fragment identifier is given by the SVG specification, not the XHTML specification (i.e., the context where the URI appears).

Given The semantics of a URI "U#F", fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [ RFC2046 ] of a representation potentially retrieved by dereferencing URI "U", representation, even though such a retrieval is only performed if the ( <a href="#def-secondary-resource" shape="rect"> secondary </a> ) resource identified by "U#F" URI is determined by interpreting "F" according to dereferenced. If no such representation exists, then the specification associated with semantics of the Internet Media Type fragment are considered unknown and, effectively, unconstrained. Fragment identifier semantics are independent of the representation. URI scheme and thus cannot be redefined by URI scheme specifications.

Interpretation of the fragment identifier during a retrieval action is performed solely by the agent; the fragment identifier is not passed to other systems during the process of retrieval. This means that some intermediaries in the Web architecture (such as proxies) have no interaction with fragment identifiers and that redirection (in HTTP [ RFC2616 ], for example) does not account for them. deleted text: </p> <p> Note also that one can use since dereferencing a URI (e.g., using HTTP) does not involve sending a fragment identifier to a server or other agent, certain access methods (e.g., HTTP PUT, POST, and DELETE) cannot be used to interact with secondary resources.

As with any URI, use of a fragment identifier even if one component does not have imply that a retrieval action will take place. A URI with a deleted text: representation available for interpreting the fragment identifier (one can may be used to refer to the secondary resource without any implication that the primary resource is accessible or will ever be accessed. One may compare two such URIs, for example). URIs with fragment identifiers without a retrieval action. Parties that draw conclusions about the interpretation of a fragment identifier without retrieving a representation do so at their own risk; such interpretations are not authoritative.

3.3.2. Fragment Identifiers and Multiple Representations

For a given resource, an agent may have the choice between representation data in more than one data format (through HTTP content negotiation, for example). Since different Individual data formats may define different their own restrictions on, or structure within, the fragment identifier semantics, it is important to note syntax for specifying different types of subsets, views, or external references that are identifiable as secondary resources by design, that media type. If the primary resource has multiple representations, as is often the case for resources whose representation is selected based on attributes of the secondary resource retrieval request ("content negotiation"), then whatever is identified by a URI with a the fragment identifier is expected to should be the same consistent across all representations. Thus, if a fragment has defined semantics in any one representation, of those representations: each representation should either define the fragment is identified for all such that it corresponds to the same secondary resource, regardless of them, even though a particular data format may not how it is represented, or the fragment should be able to represent it. left undefined by the representation (i.e., not found).

Suppose, for example, that the authority responsible for owner of "http://weather.example.com/oaxaca/map#zicatela" provides representations of the resource identified by http://weather.example.com/oaxaca/map using three image formats: SVG, PNG, and JPEG/JFIF. The SVG specification defines semantics for fragment identifiers while the other specifications do not. It is not considered an error that only one of the data formats specifies semantics for the fragment identifier. Because the Web is a distributed system in which formats and agents are deployed in a non-uniform manner, the architecture allows this sort of discrepancy. This design allows content authors to take advantage of new data formats while still ensuring reasonable backward-compatibility for users whose agents do not yet implement them.

Inconsistent fragment identifier semantics are URI overloading is one potential source possible consequence of <a href="#URI-ambiguity" shape="rect"> URI ambiguity </a>. inconsistent fragment identifier semantics.

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

3.4.1. Inconsistencies between Metadata and Representation Data

Inconsistencies between the data format of representation data and assigned representation metadata do occur. Examples that have been observed in practice include:

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

User agents Agents should detect such inconsistencies but should not resolve them without deleted text: involving the user. consent of the user; see the section on error handling for more information.

Thus, for example, if the parties responsible for "weather.example.com" mistakenly label the satellite photo of Oaxaca as "image/gif" instead of "image/jpeg", and if Nadia's browser detects a problem, Nadia's browser must not deleted text: silently ignore the problem and render (e.g., by simply rendering the JPEG image. image) without Nadia's consent. Nadia's browser can notify Nadia of the problem or notify Nadia and take corrective action. Of course, user agent designers developers should not ignore usability issues when handling this type of error; notification may be discreet, and handling may be tuned to meet the user's preferences. See the TAG finding " Client handling of MIME headers " for more in-depth discussion and examples. </p> <p> Furthermore, server managers can help reduce the risk of error through careful assignment of representation metadata (especially that which applies across representations). The section on <a href="#xml-media-types" shape="rect"> media types for XML </a> presents an example of reducing the risk of error by providing no metadata about character encoding when serving XML. </p> </div> </div> <div class="section"> <h3> 3.5. <a name="safe-interaction" id="safe-interaction" shape="rect"> Safe Interactions </a> </h3> <div class="boxedtext"> <p> <span class="storylab"> Story </span> </p> <div class="story"> <p> Nadia decides to book a vacation to Oaxaca at "booking.example.com." She enters data into a series of online forms and is ultimately asked for credit card information to purchase the airline tickets. She provides this information in another form. When she presses the "Purchase" button, her browser opens another network connection to the server at "booking.example.com" and sends a message composed of form data using the POST method. Note that this is not a <a href="#safe-interaction" shape="rect"> safe interaction </a> ; Nadia wishes to change the state of the system by exchanging money for airline tickets. </p> <p> The server reads the POST request, discussion and after performing the booking transaction returns a message to Nadia's browser that contains a examples.

Furthermore, representation of providers can help reduce the results risk of error through careful assignment of deleted text: Nadia's request. The representation data is in XHTML so metadata (especially that it can be saved or printed out which applies across representations). The section on media types for Nadia's records. Note that neither the data transmitted with the POST nor the data received in XML presents an example of reducing the response necessarily correspond to any resource named risk of error by a URI. providing no metadata about character encoding when serving XML.

3.5.1. Unsafe Interactions and Accountability

It is a breakdown of the Web architecture if agents cannot use URIs to reconstruct a "paper trail" of transactions, transaction results, i.e., to refer to receipts and other evidence of accepting an obligation. Indeed, each electronic mail message includes a unique message identifier, one reason why email is so useful for managing accountability (since, for example, email can be copied to public archives). On the other hand, HTTP servers and deployed user agents do not generally keep records of POST transactions, making it difficult for all parties to reconstruct a series of transactions.

There are mechanisms in HTTP, not widely deployed, to remedy this situation. HTTP servers can assign a URI to the results of a POST transaction using the "Content-Location" header (described in section 14.14 of [ RFC2616 ]), and allow authorized parties to retrieve a record of the transaction thereafter via this URI (the value of URI persistence is apparent in this case). User agents can provide an interface for managing transactions where the user agent has incurred an obligation on behalf of the user.

3.6.1. Representation availability

The authority responsible for a resource A URI owner may supply zero or more representations of a resource. The authority the resource identified by that URI. That agent is also responsible for accepting or rejecting requests to modify a resource, the resource identified by that URI, for example, by configuring a server to accept or reject HTTP PUT data based on Internet Media Type, media type, validity constraints, or other constraints.

For example, the owner of an XML Namespace should provide namespace representations ; below we discuss useful characteristics of a namespace representation.

3.6.2. URI Persistence

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

Since representations are used to communicate resource state, persistence is directly affected by how well representations are served. Service breakdowns include:

• Inconsistent representations served. Note the difference between a resource URI owner changing representations predictably in light of the nature of the resource (the changing weather of Oaxaca) and the URI 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.

4.2.1. Versioning

Binary data formats are those in There is typically a (long) transition period during which portions multiple versions of the data a format, protocol, or agent 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. simultaneously in use.

4.2.2. Versioning and used with little or no conversion. XML Namespace Policy

It is important Dirk and Nadia have chosen a particular namespace change policy that allows them to emphasize avoid changing the namespace name whenever they make changes that intuition as to such matters as data size and processing speed are do not affect conformance of deployed content and software. They might have chosen a reliable guide in data format design; quantitative studies are essential different policy, for example that any new element or attribute has to belong to a correct understanding namespace other than the original one. Whatever the chosen policy, it should set clear expectations for users of the trade-offs. Therefore, data format.

<strong> Note: </strong> Text (i.e., a sequence As an example of deleted text: characters from a repertoire) is distinct from serving data with a media type beginning with "text/". Although XML-based formats are textual, many such formats are not primarily comprised change policy designed to reflect the variable stability of phrases in natural language. See a namespace, consider the section on <a href="#xml-media-types" shape="rect"> media types for XML W3C namespace policy for issues documents on the W3C Recommendation track. The policy sets expectations that arise when "text/" is used the Working Group responsible for the namespace may modify it in any way until a certain point in deleted text: conjunction with an XML-based format. </p> <p> See TAG issue <a href="http://www.w3.org/2001/tag/ilist#binaryXML-30" shape="rect"> binaryXML-30 </a>. </p> </div> <div class="section"> <h3> 4.2. <a name="ext-version" id="ext-version" shape="rect"> Versioning and Extensibility </a> </h3> <p> Extensibility and versioning are strategies to help manage the natural evolution process ("Candidate Recommendation") at which point W3C constrains the set of information on possible changes to the Web and technologies used namespace in order to represent that information. promote stable implementations.

For more information on about versioning strategies and agent behavior in Note that since namespace names are URIs, the face owner of unrecognized extensions, see TAG issue <a href="http://www.w3.org/2001/tag/issues.html#XMLVersioning-41" shape="rect"> XMLVersioning-41 </a> and "Web Architecture: Extensible Languages" [ <a href="#EXTLANG" shape="rect"> EXTLANG </a> ]. a namespace URI has the authority to decide the namespace change policy.

4.2.1. <a name="versioning" id="versioning" shape="rect"> Versioning 4.2.3. Extensibility

There is typically a (long) Designers can facilitate the transition period process by making careful choices about extensibility during which multiple versions the design of a format, protocol, language or agent are simultaneously in use. protocol specification.

Nadia and Dirk are designing an XML data format to encode data about Application needs determine the film industry. They provide most appropriate extension strategy for deleted text: extensibility by using XML namespaces and creating a schema that allows the inclusion, in certain places, of elements from any namespace. When they revise their format, Nadia proposes a new optional "lang" attribute on the "film" element. Dirk feels that such a change requires them to assign a new namespace name, which might require changes specification. For example, applications designed to deployed software. Nadia explains operate in closed environments may allow specification designers to Dirk define a versioning strategy that their choice would be impractical at the scale of the Web. As part of defining an extensibility strategy mechanism, specification designers should set expectations about agent behavior in conjunction with their namespace policy allows certain changes that do not affect conformance the face of existing content and software, and thus no change to unrecognized extensions.

Two strategies have emerged as being particularly useful:

1. "Must ignore": The agent ignores any content it does not recognize.
2. "Must understand": The agent treats unrecognized markup as an error condition.

A powerful design approach is required. They chose this policy for the language to help them meet their goals allow either form of reducing extension, but to distinguish explicitly between them in the cost of change. syntax.

Dirk Additional strategies include prompting the user for more input, automatically retrieving data from available links, and Nadia have chosen falling back to default behavior. More complex strategies are also possible, including mixing strategies. For instance, a particular namespace change policy that allows them language can include mechanisms for overriding standard behavior. Thus, a data format can specify "must ignore" semantics but also allow people to avoid changing the namespace name whenever they make changes create extensions that do not affect conformance of deployed content and software. They might have chosen override that semantics in light of application needs (for instance, with "must understand" semantics for a different policy, particular extension).

Extensibility is not free. Providing hooks for example that any new element or attribute has to belong extensibility is one of many requirements to a namespace other than be factored into the original one. Whatever costs of language design. Experience suggests that the chosen policy, it should set clear expectations for users long term benefits of extensibility generally outweigh the format. costs.

4.2.4. Composition of Data Formats </span> </p> <p class="practice"> Format designers SHOULD document change policies

Many modern data format include mechanisms for XML namespaces. composition. For example:

• It is possible to reflect the variable stability of a namespace, consider embed text comments in some image formats, such as JPEG/JFIF. Although these comments are embedded in the <a href="http://www.w3.org/1999/10/nsuri" shape="rect"> W3C namespace policy </a> for documents containing data, they have little or no effect on the W3C Recommendation track. The policy sets expectations that the Working Group responsible for display of the namespace may modify it in any way until image.
• 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.
• RDF allows well-defined mixing of vocabularies, and allows text and XML to be used as a data type values within a statement having clearly defined semantics.

These relationships can be mixed and nested arbitrarily. In principle, a certain point in the process ("Candidate Recommendation") at SOAP message can contain an SVG image that contains an RDF comment which point W3C constrains the set possible changes refers to a vocabulary of terms for describing the namespace in order to promote stable implementations. image.

Note however, that deleted text: since namespace names are URIs, the party (if any) responsible for general XML there is no semantic model that defines the interactions within XML documents with elements and/or attributes from a variety of namespaces. Each application must define how namespaces interact and what effect the namespace URI of an element has on the authority to decide the namespace change policy. element's ancestors, siblings, and descendants.

See TAG issues mixedUIXMLNamespace-33 , xmlFunctions-34 , and RDFinXHTML-35 .

4.4.1. URI References

Note that when content, presentation, and interaction are separated by design, agents need to recombine them. There is a recombination spectrum, with "client does all" at one end and "server does all" at the other. There Links are advantages to each: recombination on the server allows the server to send out generally smaller amounts commonly expressed using URI references (defined in section 4.2 of data that can be tailored to specific devices (such as mobile phones). However, such data will not be readily reusable by other clients and [ URI ]), which may not allow client-side agents to perform useful tasks unanticipated by the author. When be combined with a client does the work of recombination, content is likely base URI to be more reusable by yield a broader audience and more robust. However, such data may be usable URI. Section 5.1 of greater size [ URI ] explains different mechanisms for establishing a base URI for a resource and may require more computation by establishes a precedence among the client. </p> <p> Of course, it may not always be desirable to reach various mechanisms. For instance, the widest possible audience. Application context base URI may require a very specific display (for be a legally-binding transaction, URI for example). Also, digital signature technology, <a href="#id-access" shape="rect"> access control </a>, the resource, or specified in a representation (see the base elements provided by HTML and other technologies are appropriate for controlling access to content. XML, and the HTTP 'Content-Location' header). See also the section on links in XML .

Some data formats are designed Agents resolve a URI reference before using the resulting URI to describe presentation (including SVG and XSL Formatting Objects). Data formats such as these demonstrate that one can only separate interact with another agent. URI references help in content from presentation (or interaction) so far; at some point it becomes necessary management by allowing content authors to design a representation locally, i.e., without concern for which global identifier may later be used to refer to deleted text: talk about presentation. Per the principle of orthogonal specifications, these data formats should <em> only </em> address presentation issues. </p> <p> See the TAG issues <a href="http://www.w3.org/2001/tag/ilist#formattingProperties-19" shape="rect"> formattingProperties-19 </a> and <a href="http://www.w3.org/2001/tag/ilist#contentPresentation-26" shape="rect"> contentPresentation-26 </a>. associated resource.

4.5.1. When to Use an XML-Based Format </span>

XML defines textual data formats that are naturally suited to describing data objects which are hierarchical and processed in a chosen sequence. It is widely, but not universally, applicable for data formats; an audio or video format, for example, is unlikely to be well suited to expression in XML. Design constraints that would suggest the use of XML include:

1. Requirement for identifying links a hierarchical structure.
2. The data's usefulness should outlive the tools currently used to other resources and process it (though obviously XML can be used for short-term needs as well).
3. Ability to portions support internationalization in a self-describing way that makes confusion over coding options unlikely.
4. Early detection of representation encoding errors with no requirement to "work around" such errors.
5. A high proportion of human-readable textual content.
6. Potential composition of the data (via fragment identifiers). </p> format with other XML-encoded formats.

4.5.2. Links in XML </span> </p> <p class="practice"> Language designers SHOULD provide

Sophisticated linking mechanisms have been invented for XML formats. XPointer allows links to address content that allow Web-wide linking, does not just internal document linking. </p> </div> <div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a name="generic-uri" id="generic-uri" shape="rect"> Generic URIs </a> </span> </p> <p class="practice"> Language designers SHOULD allow authors to use URIs without constraining them to a limited set of URI schemes. </p> </div> <p> What agents do with a hypertext link have an explicit, named anchor. XLink is not constrained by Web architecture and may depend on application context. Users of the an appropriate specification for representing links in hypertext XML applications. XLink allows links deleted text: expect to be able to navigate links among representations. Data formats that do not allow authors have multiple ends and to create hypertext links lead be expressed either inline or in "link bases" stored external to the creation any or all of deleted text: "terminal nodes" on the Web. </p> <div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a name="use-hypertext-links" id="use-hypertext-links" shape="rect"> Hypertext resources identified by the links </a> </span> it contains.

Designers of XML-based formats should consider using XLink and, for defining fragment identifier syntax, using the expected user interface paradigm. XPointer framework and XPointer element() Schemes.

See TAG issue xlinkScope-23 .

4.4.1. <a name="uri-refs" id="uri-refs" shape="rect"> URI References 4.5.3. XML Namespaces

Agents resolve a URI reference before using How can one ensure that there are no naming conflicts when elements from different XML-based data formats are mixed? For example, suppose that one designer defines the resulting URI para element in an XML format to interact with identify paragraphs, and another agent. URI references help designer defines the para element in content management by allowing authors a second format to design identify parachutes. "Namespaces in XML" [ XMLNS ] provides a representation locally, i.e., without concern mechanism for which establishing globally unique names.

Specification designers who declare namespaces thus provide a global identifier may later be used context for instances of the data format. Establishing this global context allows those instances (and portions thereof) to refer be re-used and combined in novel ways not yet imagined. Failure to the associated resource. provide a namespace makes such re-use more difficult, perhaps impractical in some cases.

Many data formats Attributes are <a name="xml-based" id="xml-based"> <dfn> XML-based </dfn> </a>, always scoped by the element on which they appear. An attribute that is to say they conform to the syntax rules defined "global," that is, one that might meaningfully appear on elements of any type, including elements in other namespaces, should be explicitly placed in a namespace. Local attributes, ones associated with only a particular element type, need not be included in a namespace since their meaning will always be clear from the XML specification <a href="#XML10" shape="rect"> [XML10] </a>. This section discusses issues that are specific to such formats. Anyone seeking guidance context provided by that element.

The xsi:type attribute, provided by W3C XML Schema for use in this area XML instance documents, is urged an example of a global attribute. It can be used by authors of any vocabulary to consult the "Guidelines For make an assertion in instance data about the Use type of XML in IETF Protocols" <a href="#IETFXML" shape="rect"> [IETFXML] </a>, the element on which contains a thorough discussion of it appears. The type attribute occurs in the considerations that govern whether or not W3C XML ought to Schema namespace "http://www.w3.org/2001/XMLSchema" and must always be used, as well as specific guidelines fully qualified. The frame attribute on how it ought to be used. While it an HTML table is directed at Internet applications with specific reference to protocols, an example of a local attribute. There is no value in placing that attribute in a namespace since the discussion attribute is generally applicable unlikely to Web scenarios as well. be useful on an element other than an HTML table.

The discussion here should be seen as ancillary to Applications that rely on DTD processing must impose additional constraints on the content use of <a href="#IETFXML" shape="rect"> [IETFXML] </a>. Refer also to "XML Accessibility Guidelines" <a href="#XAG" shape="rect"> [XAG] namespaces. DTDs perform validation based on the lexical form of the element and attribute names in the document. This makes prefixes syntactically significant in ways that are not anticipated by [ XMLNS for help designing ].

4.5.4. Namespace Representation

There are many reasons to provide information about a hierarchical structure. namespace. A person might want to:

• understand its purpose,
• The data's usefulness should outlive learn how to use the tools currently used markup vocabulary in the namespace,
• find out who controls it,
• request authority to process it (though obviously XML can access schemas or collateral material about it, or
• report a bug or situation that could be used for short-term needs as well). considered an error in some collateral material.

A processor might want to:

• Ability to support internationalization in retrieve a self-describing way that makes confusion over coding options unlikely. schema, for validation,
• Early detection of encoding errors with no requirement to "work around" such errors. retrieve a style sheet, for presentation, or
• A high proportion of human-readable textual content. retrieve ontologies, for making inferences.
<li> Potential composition of the

In general, there is no established best practice for creating a namespace representation. Application expectations will influence what data format with other XML-encoded formats. </li> </ol> </div> <div class="section"> <h4> 4.5.2. <a name="xml-links" id="xml-links" shape="rect"> Links or formats are used to create a namespace representation. Application expectations will also influence whether relevant information appears in XML the namespace representation itself or is referenced from it.

Designers For example, the following are examples of formats used to create namespace representations: [ OWL10 ], [ RDDL ], [ XMLSCHEMA ], and [ XHTML11 ]. Each of XML-based these formats should consider using XLink and, meets different requirements described above for defining fragment identifier syntax, using satisfying the XPointer framework needs of an agent that wants more information about the namespace. Note, however, issues related to fragment identifiers and XPointer element() Schemes. multiple representations if content negotiation is used with namespace representations.

See TAG issue <a href="http://www.w3.org/2001/tag/ilist#xlinkScope-23" shape="rect"> xlinkScope-23 issues namespaceDocument-8 and abstractComponentRefs-37 .

4.5.3. <a name="xml-namespaces" id="xml-namespaces" shape="rect"> 4.5.5. QNames in XML deleted text: Namespaces

The authority responsible Section 3 of "Namespaces in XML" [ XMLNS ] provides a syntactic construct known as a QName for "weather.example.com" realizes that it can provide more interesting representations by creating instances that consist the compact expression of elements defined qualified names in different <a href="#xml-based" shape="rect"> XML-based formats </a>, such XML documents. A qualified name is a pair consisting of a URI, which names a namespace, and a local name placed within that namespace. "Namespaces in XML" provides for the use of QNames as XHTML, SVG, names for XML elements and MathML. attributes.

How do the application designers ensure that there are no naming conflicts when they combine elements from different formats (for example, suppose that Other specifications, starting with [ XSLT10 ], have employed the "p" idea of using QNames in contexts other than element is defined and attribute names, for example in two or more attribute values and in element content. However, general XML formats)? "Namespaces processors cannot reliably recognize QNames as such when they are used in XML" [ <a href="#XMLNS" shape="rect"> XMLNS </a> ] provides a mechanism for establishing a globally unique name that can be understood attribute values and in any context. </p> <p> Language specification designers that declare namespaces thus provide a global context element content; for instances of example, the data format. Establishing this global context allows those instances (and portions thereof) to be re-used and combined in novel ways not yet imagined. Failure syntax of QNames overlaps with that of URIs. Experience has also revealed other limitations to provide a namespace makes QNames, such re-use more difficult, perhaps impractical in some cases. as losing namespace bindings after XML canonicalization.

The <code> type </code> attribute from W3C XML Schema is an example of a global attribute. It can be used by authors of any vocabulary to make an assertion about the type of For more information, see the element on which it appears. The <code> type </code> attribute occurs TAG finding " Using QNames as Identifiers in Content " .

Because QNames are compact, some specification designers have adopted the W3C XML Schema namespace and must always be fully qualified. The <code> frame </code> attribute on an HTML table is an example same syntax as a means of identifying resources. Though convenient as a local attribute. shorthand notation, this usage has a cost. There is no value in placing that attribute in single, accepted way to convert a namespace since QName into a URI or vice versa. Although QNames are convenient, they do not replace the attribute is unlikely to be useful on an element other than an HTML table. </p> <p> Applications that rely on DTD processing must impose additional constraints on URI as the use identification mechanism of deleted text: namespaces. DTDs perform validation based on the lexical form Web. The use of the element and attribute names in the document. This makes prefixes syntactically significant in ways that are not anticipated by [ <a href="#XMLNS" shape="rect"> XMLNS </a> ]. QNames to identify Web resources without providing a mapping to URIs is inconsistent with Web architecture.

For examples of QName-to-URI mappings, see [ RDF10 ]. See also TAG issues rdfmsQnameUriMapping-6 , qnameAsId-18 , and abstractComponentRefs-37 .

4.5.6. XML namespace the elements belong to. Since the namespace is identified by ID Semantics

Consider the URI "http://weather.example.com/2003/format", she asks her browser to retrieve a representation following fragment of XML: <section name="foo"> . Does the namespace via that URI. Nadia is requesting section element have what the <a name="def-namespace-document" id="def-namespace-document"> <dfn> namespace document </dfn> </a>. </p> <p> Nadia gets back some useful data that allows her XML Recommendation refers to learn more about as the data format. Nadia's browser may also be able to perform some operations automatically (i.e., unattended ID foo ? One cannot answer this question by a human overseer) given data that has been optimized for software agents. For example, her browser might, on Nadia's behalf, download additional agents to process examining the element and render its attributes alone. In XML, the format. </p> </div> </div> <p> There are many reasons to provide information about quality of "being an ID" is associated with the type of an attribute, not its name. Finding the IDs in a namespace. A person might want to: document requires additional processing.

1. learn how to use Processing the markup vocabulary in document with a processor that recognizes DTD attribute list declarations (in the namespace, </li> <li> find out who controls it, </li> <li> request authority to access schemas or collateral material about it, external or </li> <li> report internal subset) might reveal a bug or situation declaration that could be considered identifies the name attribute as an error in some collateral material. </li> </ul> <p> ID. Note: This processing is not necessarily part of validation. A non-validating, DTD-aware processor might want to: </p> <ul> <li> retrieve a schema, for validation, can perform ID assignment.
2. retrieve Processing the document with a style sheet, for presentation, or W3C XML schema might reveal an element declaration that identifies the name attribute as an xs:ID .
3. deleted text: retrieve ontologies, for making inferences. </li> </ul> <p> In general, there is no established best practice for creating a namespace document. Application expectations will influence what data format or formats are used to create a namespace document. Application expectations will also influence whether relevant information appears in practice, processing the deleted text: namespace document itself or is referenced from it. </p> <div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a name="namespace-docs" id="namespace-docs" shape="rect"> Namespace documents with another schema language, such as RELAX NG [ RELAXNG </span> </p> <p class="practice"> Resource owners who publish an XML namespace name SHOULD make available material intended for people to read and material optimized for software agents in order to meet ], might reveal the needs attributes declared to be of those who will use ID in the namespace vocabulary. </p> </div> <p> For example, XML Schema sense. Many modern specifications begin processing XML at the following are examples of formats used to create namespace documents: [ <a href="#OWL10" shape="rect"> OWL10 </a> ], Infoset [ <a href="#RDDL" shape="rect"> RDDL INFOSET ], ] level and do not specify normatively how an Infoset is constructed. For those specifications, any process that establishes the ID type in the Infoset (and Post Schema Validation Infoset ( PSVI ) defined in [ XMLSCHEMA ], and [ <a href="#XHTML11" shape="rect"> XHTML11 </a> ]. Each ]) may usefully identify the attributes of these formats meets different requirements described above type ID.
4. In practice, applications may have independent means of specifying ID-ness as provided for satisfying and specified in the needs of an agent XPointer specification.

To further complicate matters, DTDs establish the ID type in the Infoset whereas W3C XML Schema produces a PSVI but does not modify the original Infoset. This leaves open the possibility that wants more information about a processor might only look in the namespace. Note, however, issues related to <a href="#frag-multiple-reps" shape="rect"> fragment identifiers Infoset and multiple representations </a> if content negotiation is used with namespace documents. consequently would fail to recognize schema-assigned IDs.

The TAG expects to continue to work with other groups to help resolve open questions about establishing "ID-ness" in XML formats. See TAG issues <a href="http://www.w3.org/2001/tag/ilist#namespaceDocument-8" shape="rect"> namespaceDocument-8 </a> and <a href="http://www.w3.org/2001/tag/ilist.html#abstractComponentRefs-37" shape="rect"> abstractComponentRefs-37 issue xmlIDSemantics-32 .

4.5.5. <a name="xml-qnames" id="xml-qnames" shape="rect"> QNames in 4.5.7. Media Types for XML

Section 3 of "Namespaces in XML" [ <a href="#XMLNS" shape="rect"> XMLNS </a> ] provides a syntactic construct known as a QName for the compact expression of qualified names in XML documents. A qualified name is a pair consisting of a URI, which names a namespace, and a local name placed within that namespace. "Namespaces in XML" provides for RFC 3023 defines the use of QNames as names for XML elements Internet media types "application/xml" and attributes. </p> <p> Other specifications, starting with [ <a href="#XSLT10" shape="rect"> XSLT10 </a> ], have employed the idea of using QNames in contexts other than element "text/xml", and attribute names, describes a convention whereby XML-based data formats use Internet media types with a "+xml" suffix, for example in attribute values and in element content. However, general XML processors cannot recognize QNames "image/svg+xml".

These Internet media types create two problems: First, for data identified as such when they are used in attribute values and in element content; they "text/*", Web intermediaries are indistinguishable from URIs. Experience has also revealed other limitations allowed to QNames, such as losing namespace bindings after XML canonicalization. "transcode", i.e., convert one character encoding to another. Transcoding may make the self-description false or may cause the document to be not well-formed.

For more information, see Second, representations whose Internet media types begin with "text/" are required, unless the TAG finding <cite> " <a href="http://www.w3.org/2001/tag/doc/qnameids.html" shape="rect"> Using QNames as Identifiers charset parameter is specified, to be considered to be encoded in Content </a> " </cite>. </p> <p> Because QNames are compact, some specifications have adopted US-ASCII. Since the deleted text: same syntax deleted text: as a means of identifying Web resources. Though convenient as a shorthand notation, this usage has a cost. There XML is no single, accepted way designed to convert a QName into a URI or vice-versa. Although QNames are convenient, they do not replace the URI as make documents self-describing, it is good practice to omit the identification mechanism of charset parameter, and since XML is very often not encoded in US-ASCII, the deleted text: Web. The use of QNames to identify Web resources without providing a mapping to URIs is inconsistent with Web architecture. "text/" Internet media types effectively precludes this good practice.

4.5.8. Fragment Identifiers in XML ], might reveal

The section on media types and fragment identifier semantics discusses the attributes interpretation of type ID. Many modern specifications begin processing XML at fragment identifiers. Designers of an XML-based data format specification should define the Infoset semantics of fragment identifiers in that format. The XPointer Framework [ <a href="#INFOSET" shape="rect"> INFOSET XPTRFR ] level and do not specify normatively how provides an Infoset is constructed. For those specifications, any process that establishes interoperable starting point.

When the ID media type in the Infoset (and Post Schema Validation Infoset ( <acronym> PSVI </acronym> ) assigned to representation data is "application/xml", there are no semantics defined for fragment identifiers, and authors should not make use of fragment identifiers in [ <a href="#XMLSCHEMA" shape="rect"> XMLSCHEMA </a> ]) may usefully identify such data. The same is true if the attributes of assigned media type ID. </li> </ol> <p> To further complicate matters, DTDs establish has the ID type suffix "+xml" (defined in "XML Media Types" [ RFC3023 ]), and the Infoset whereas W3C data format specification does not specify fragment identifier semantics. In short, just knowing that content is XML deleted text: Schema produces a PSVI but does not modify provide information about fragment identifier semantics.

Many people assume that the original Infoset. This leaves open fragment identifier #abc , when referring to XML data, identifies the possibility that a processor might only look element in the Infoset and consequently would fail to recognize schema-assigned IDs. document with the ID "abc". However, there is no normative support for this assumption.

See TAG issue <a href="http://www.w3.org/2001/tag/issues.html#xmlIDSemantics-32" shape="rect"> xmlIDSemantics-32 fragmentInXML-28 .

6.1. Architectural Specifications

<a name="RDDL" id="RDDL" shape="rect"> RDDL ATAG10

<a href="http://www.tbray.org/tag/rddl/rddl3.html" shape="rect"> Resource Directory Description Language (RDDL) Authoring Tool Accessibility Guidelines 1.0 </cite>, , J. Borden, T. Bray, eds., 1 June 2003. This document is Treviranus, C. McCathieNevile, I. Jacobs, J. Richards, Editors, W3C Recommendation, 3 February 2000, http://www.w3.org/TR/2000/REC-ATAG10-20000203 . Latest version available at http://www.tbray.org/tag/rddl/rddl3.html. </dd> <dt> <a name="RELAXNG" id="RELAXNG" shape="rect"> RELAXNG </a> </dt> <dd> The <a href="http://www.relaxng.org/" shape="rect"> RELAX NG </a> schema language project. http://www.w3.org/TR/ATAG10 .

<a name="REST" id="REST" shape="rect"> REST CHARMOD

<a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm" shape="rect"> Representational State Transfer (REST) Character Model for the World Wide Web 1.0: Fundamentals </cite>, Chapter 5 of "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Thesis of R. , T. Fielding, 2000. Available Texin, M. J. Dürst, F. Yergeau, R. Ishida, M. Wolf, Editors, W3C Working Draft (work in progress), 25 February 2004, http://www.w3.org/TR/2004/WD-charmod-20040225/ . Latest version available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm. http://www.w3.org/TR/charmod/ .

<a name="RFC977" id="RFC977" shape="rect"> RFC977 DIPRINCIPLES

IETF <a href="http://www.ietf.org/rfc/rfc977.txt" shape="rect"> RFC 977: Network News Transfer Protocol Device Independence Principles </cite>, B. Kantor, P. Lapsley, February 1986. Available , R. Gimson, Editor, W3C Working Group Note, 1 September 2003, http://www.w3.org/TR/2003/NOTE-di-princ-20030901/ . Latest version available at http://www.ietf.org/rfc/rfc977.txt. http://www.w3.org/TR/di-princ/ .

<a name="RFC2141" id="RFC2141" shape="rect"> RFC2141 EXTLANG

IETF <a href="http://www.ietf.org/rfc/rfc2141.txt" shape="rect"> RFC 2141: URN Syntax Web Architecture: Extensible Languages , R. Moats, May 1997. Available T. Berners-Lee, D. Connolly, 10 February 1998. This W3C Note is available at http://www.ietf.org/rfc/rfc2141.txt. http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210.

<a name="RFC2326" id="RFC2326" shape="rect"> RFC2326 Fielding

IETF <a href="http://www.ietf.org/rfc/rfc2326.txt" shape="rect"> RFC 2326: Real Time Streaming Protocol (RTSP) Principled Design of the Modern Web Architecture , H. Schulzrinne, A. Rao, R. Lanphier, April 1998. Available at: http://www.ietf.org/rfc/rfc2326.txt. 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.

<a name="RFC2718" id="RFC2718" shape="rect"> RFC2718 QA

IETF <a href="http://www.ietf.org/rfc/rfc2718.txt" shape="rect"> RFC 2718: QA Framework: Specification Guidelines deleted text: for new URL Schemes </cite>, L. Masinter, H. Alvestrand, , D. Zigmond, R. Petke, Hazaël-Massieux, L. Henderson, L. Rosenthal, Editors, W3C Candidate Recommendation (work in progress), 10 November 1999. Available at: http://www.ietf.org/rfc/rfc2718.txt. </dd> <dt> <a name="RFC2818" id="RFC2818" shape="rect"> RFC2818 </a> </dt> <dd> IETF <cite> <a href="http://www.ietf.org/rfc/rfc2818.txt" shape="rect"> RFC 2818: HTTP Over TLS 2003, http://www.w3.org/TR/2003/CR-qaframe-spec-20031110/ . Latest version </cite>, E. Rescorla, May 2000. Available at: http://www.ietf.org/rfc/rfc2818.txt. available at http://www.w3.org/TR/qaframe-spec/ .

<a name="RFC3023" id="RFC3023" shape="rect"> RFC3023 RFC1958

IETF <a href="http://www.ietf.org/rfc/rfc3023.txt" shape="rect"> RFC 3023: XML Media Types 1958: Architectural Principles of the Internet </cite>, M. Murata, S. St. Laurent, D. Kohn, January 2001. , B. Carpenter, June 1996. Available at: http://www.rfc-editor.org/rfc/rfc3023.txt at http://www.ietf.org/rfc/rfc1958.txt.

<a name="RFC3236" id="RFC3236" shape="rect"> RFC3236 UAAG10

IETF <a href="http://www.ietf.org/rfc/rfc3236.txt" shape="rect"> RFC 3236: The 'application/xhtml+xml' Media Type User Agent Accessibility Guidelines 1.0 </cite>, M. Baker, P. Stark, January 2002. Available at: http://www.rfc-editor.org/rfc/rfc3236.txt , I. Jacobs, J. Gunderson, E. Hansen, Editors, W3C Recommendation, 17 December 2002, http://www.w3.org/TR/2002/REC-UAAG10-20021217/ . Latest version available at http://www.w3.org/TR/UAAG10/ .

<a name="UNICODE" id="UNICODE" shape="rect"> UNICODE WCAG20

See the <a href="http://www.unicode.org/" shape="rect"> Unicode Consortium home page Web Content Accessibility Guidelines 2.0 for information about the latest , B. Caldwell, W. Chisholm, G. Vanderheiden, J. White, Editors, W3C Working Draft (work in progress), 11 March 2004, http://www.w3.org/TR/2004/WD-WCAG20-20040311/ . Latest version of Unicode and character repertoires. available at http://www.w3.org/TR/WCAG20/ .

<a name="UniqueDNS" id="UniqueDNS" shape="rect"> UniqueDNS WSA

<a href="http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm" shape="rect"> IAB Technical Comment on the Unique DNS Root Web Services Architecture </cite>, B. Carpenter, 27 September 1999. Available , D. Orchard, D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, Editors, W3C Working Group Note, 11 February 2004, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/ . Latest version available at http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm. http://www.w3.org/TR/ws-arch/ .

<a name="XMPP" id="XMPP" shape="rect"> XMPP XAG

The <a href="http://www.ietf.org/html.charters/xmpp-charter.html" shape="rect"> Extensible Messaging and Presence Protocol ( <acronym> XMPP </acronym> ) IETF XML Accessibility Guidelines , D. Dardailler, S. B. Palmer, C. McCathieNevile, Editors, W3C Working Group Draft (work in progress), 3 October 2002, http://www.w3.org/TR/2002/WD-xag-20021003 . Latest version is developing "an open, XML-based protocol for near real-time extensible messaging and presence. It is the core protocol of the Jabber Instant Messaging and Presence technology..." available at http://www.w3.org/TR/xag .