Latest editor's draft:
Ian Jacobs, W3C
See acknowledgments .
Copyright © 2002-2004 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark , document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
The World Wide Web is a network-spanning information space of resources interconnected by links[skw1] . This information space is the basis of, and is shared by, a number of information systems. Within each of these systems, agents (people and software) retrieve, create, display, analyze, and reason about resources.
Web architecture includes the definition of the information space in terms of identification[skw2] and representation of its contents, and of the protocols that support the interaction of agents in an information system making use of the space. Web architecture is influenced by social requirements and software engineering principles . These lead to design choices and constraints on the behavior of systems that use the Web in order to achieve desired properties of the shared information space: efficiency, scalability, and the potential for indefinite growth across languages, cultures, and media. Good practice by agents in the system is also important to the success of the system. This document reflects the three bases of Web architecture: identification, interaction, and representation.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the 8 June 2004 Editor's Draft of "Architecture of the World Wide Web, First Edition." This draft takes into account TAG decisions at the 12-14 May 2004 face-to-face meeting and the 7 June 2004 teleconference , as well as reviewer comments on the 10 May 2004 draft. Please comments about this document to the TAG mailing list firstname.lastname@example.org ( public archive ).
The TAG charter describes a process for issue resolution by the TAG. In accordance with those provisions, the TAG maintains a running issues list . The First Edition of "Architecture of the World Wide Web" does not address every issue that the TAG has accepted since it began work in January 2002. The TAG has selected a subset of issues that the First Edition does address to the satisfaction of the TAG; those issues are identified in the TAG's issues list. The TAG intends to address the remaining (and future) issues after publication of the First Edition as a Recommendation.
This document uses the concepts and terms regarding URIs as defined in draft-fielding-uri-rfc2396bis-0x, preferring them to those defined in RFC 2396. The IETF Internet Draft draft-fieldi ng-uri-rfc2396bis-0x is expected to obsolete RFC 2396 , which is the current URI standard. The TAG is tracking the evolution of draft-fielding-uri-rfc2396bis-0x.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than "work in progress." The latest information regarding patent disclosures related to this document is available on the Web.
The following principles, constraints, and good practice notes are discussed in this document and listed here for convenience. There is also a free-standing summary .
General Architecture Principles
· Error recovery (principle, 1.2.3)
· Global Identifiers (principle, 2)
· Identify with URIs (practice, 2.1)
· Avoiding URI aliases (practice, 2.3.1)
· Consistent URI usage (practice, 2.3.1)
· Avoiding URI Overloading (practice, 2.4)
· New URI schemes (practice, 2.6)
· URI opacity (practice, 2.7)
· Data-metadata inconsistency (principle, 3.4)
· Safe retrieval (principle, 3.5)
· Available representation (practice, 3.6)
· Consistent representation (practice, 3.6.1)
· Version information (practice, 4.2.1)
· Namespace policy (practice, 4.2.2)
· Extensibility mechanisms (practice, 4.2.3)
· Unknown extensions (practice, 4.2.3)
· Separation of content, presentation, interaction (practice, 4.3)
· Link mechanisms (practice, 4.4)
· Web linking (practice, 4.4)
· Generic URIs (practice, 4.4)
· Hypertext links (practice, 4.4)
· Namespace adoption (practice, 4.5.3)
· Namespace documents (practice, 4.5.4)
· QNames Indistinguishable from URIs (practice, 4.5.5)
· QName Mapping (practice, 4.5.5)
· XML and "text/*" (practice, 4.5.7)
· XML and character encodings (practice, 4.5.7)
World Wide Web ( WWW , or simply Web ) is an information space in which the items of interest, referred to as resources , are identified by global identifiers called Uniform Resource Identifiers ( URI ).[skw3]
A travel scenario is used throughout this document to illustrate [skw4] typical behavior of Web agents — people or software (on behalf of a person, entity, or process) acting on this information space. A user agent acts on behalf of a user. Software agents include servers, proxies, spiders, browsers, and multimedia players.
This scenario illustrates the three architectural bases of the Web that are discussed in this document:
1. Identification . Each resource is identified [skw6] by a URI. In this travel scenario, the resource is a periodically updated report on the weather in Oaxaca, and the URI is "http://weather.example.com/oaxaca".
2. Interaction . Protocols define the syntax and semantics of messages exchanged by agents over a network. Web agents communicate the information state of a resource through the exchange of representations . In the travel scenario, Nadia (by clicking on a hypertext link ) tells her browser to request a representation of the resource identified [skw7] by the URI in the hypertext link. The browser sends an HTTP GET request to the server at "weather.example.com". The server responds with a representation that includes XHTML data and the Internet media type "application/xhtml+xml".
3. Formats . Representations [skw8] are built from a non-exclusive set of data formats, used separately or in combination (including XHTML, CSS, PNG, XLink, RDF/XML, SVG, and SMIL animation). In this scenario, the representation data format is XHTML. While interpreting the XHTML representation data, the browser retrieves and displays weather maps identified by URIs within the XHTML.
The following illustration shows the relationship between identifier, resource, and representation.
In the remainder of this document, we highlight important architectural points regarding Web identifiers, protocols, and formats.
This document describes the properties we desire of the Web and the design choices that have been made to achieve them. It promotes re-use of existing standards when suitable, and gives guidance on how to innovate in a manner consistent with the Web architecture.
The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in the principles, constraints, and good practice notes in accordance with RFC 2119 [ RFC2119 ]. However, this document does not include conformance provisions for these reasons:
· Conforming software is expected to be so diverse that it would not be useful to be able to refer to the class of conforming software agents.
· Some of the good practice notes concern people; specifications generally define conformance for software, not people.
· The addition of a conformance section is not likely to increase the utility of the document.
This document is intended to inform discussions about issues of Web architecture. The intended audience for this document includes:
1. Participants in W3C Activities
2. Other groups and individuals designing technologies to be integrated into the Web
3. Implementers of W3C specifications
4. Web content authors and publishers
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.
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 [skw9] 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 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 that 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 (see, for example, [ VOICEXML2 ]). 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.
The important points of this document are categorized as follows:
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 limited by its slowest component."
In the design of the Web, some design choices, like the names of
elements in HTML, or the choice of the colon (:) character in URIs, are
somewhat arbitrary; if
paragraph had been chosen 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 — by software developers, content authors, site managers, users, and specification designers — increases the value of the Web.
A number of general architecture principles apply to all three bases of Web architecture.
Identification, interaction, and representation are orthogonal concepts, meaning that technologies used for identification, interaction, and representation may evolve independently. For instance:
· A generic URI syntax allows agents to function in many cases without knowing specifics of URI schemes.
When two specifications are orthogonal, one may change one without requiring changes to the other, even if one has dependencies on the other. For example, although the HTTP specification depends on the URI specification, the two may evolve independently. This orthogonality increases the flexibility and robustness of the Web. For example, one may refer by URI to an image without knowing anything about the format chosen to represent the image. This has facilitated the introduction of image formats such as PNG and SVG without disrupting existing references to image resources.
Orthogonal abstractions benefit from orthogonal specifications. Specifications should clearly indicate those features that simultaneously access information from otherwise orthogonal abstractions. For example a specification should draw attention to a feature that requires information from both the header and the body of a message.[skw12]
Although the HTTP, HTML, and URI specifications are orthogonal for the most part, they are not entirely so. Experience demonstrates that where they are not, problems have arisen:
· The HTML specification — a data format specification — includes a protocol extension of sorts: it specifies how a user agent sends HTML form data to a server (as a URI query string). The design works reasonably well, although there are limitations related to internationalization (see the TAG finding " URIs, Addressability, and the use of HTTP GET and POST " ) and the query string design impinges on the server design. Software developers (for example, of [ CGI ] applications) might have an easier time finding the specification if it were published separately and then cited from the HTTP, URI, and HTML specifications.
The HTML specification
allows content providers to instruct HTTP servers to build response headers
META element instances. This is an
abstraction violation; the software developer community would benefit from
being able to find all HTTP headers from the HTTP specification (including any
associated extension registries and specification updates per IETF process).
Perhaps as a result, this feature of the HTML specification is not widely
deployed. Furthermore, this design has led to confusion in user agent
development. The HTML specification states that
META in conjunction with
http-equiv is intended for HTTP servers, but many HTML user agents interpret
http-equiv='refresh' as a client-side instruction.
Some content authors
http-equiv approach to declare the character encoding scheme of an HTML
document. By design, this is a hint that an HTTP server should emit a
corresponding "Content-Type" header field. In practice, the use of
the hint in servers is not widely deployed. Furthermore, many user agents use
this information to override the "Content-Type" header sent by the
server, violating protocol semantics.
The information in the Web and the technologies used to represent that information change over time. Extensibility describes the property of a technology that promotes both evolution and interoperability. Some examples of successful technologies designed to allow change while minimizing disruption include:
· the fact that URI schemes are orthogonally specified;
· the use of an open set of Internet media types in mail and HTTP to specify document interpretation;
· the separation of the generic XML grammar and the open set of XML namespaces for element and attribute names;
· extensibility models in Cascading Style Sheets (CSS), XSLT 1.0, and SOAP;
· user agent plug-ins.
An example of an unsuccessful extension mechanism is HTTP mandatory extensions[skw13] . The community has sought mechanisms to extend HTTP, but apparently the costs of the mandatory extension proposal (notably in complexity) outweighed the benefits and thus hampered adoption.
Below we discuss the property of "extensibility," exhibited by URIs, some data formats, and some protocols (through the incorporation of new messages).
Subset language : one language is a subset (or, "profile") of a second language if any document in the first language is also a valid document in the second language and has the same interpretation in the second language.
Extended language : If one language is a subset of another, the latter superset is called an extended language; the difference between the languages is called the extension. Clearly, extending a language is better for interoperability than creating an incompatible language.[skw14]
Ideally, many instances of a superset language can be safely and usefully processed as though they were in the language subset. Languages that exhibit this property are said to be "extensible." Language designers can facilitate extensibility by defining how implementations must handle unknown extensions — for example, that they be ignored (in some way) or should be considered errors.
For example, from early on in the Web, HTML agents followed the convention of ignoring unknown elements. This choice left room for innovation (i.e., non-standard elements) and encouraged the deployment of HTML. However, interoperability problems arose as well. In this type of environment, there is an inevitable tension between interoperability in the short term and the desire for extensibility. Experience shows that designs that strike the right balance between allowing change and preserving interoperability are more likely to thrive and are less likely to disrupt the Web community. Orthogonal specifications help reduce the risk of disruption.
Errors occur in networked information systems. An error condition can be well-specified (e.g., well-formedness errors in XML or 4xx client errors in HTTP) or arise unpredictably. Error correction means that an agent repairs an condition so that within the system, it is as though the error never occurred. One example of error correction involves data retransmission in response to a temporary hardware failure. Error recovery means that an agent does not repair an error condition but continues processing.[skw15]
Agents frequently correct errors without user awareness, sparing users the details of complex network communications. On the other hand, it is important that agents recover from error in a way that is transparent [skw16] to users, since the agents are acting on their behalf.
An agent is not required to interrupt the user (e.g., by popping up a confirmation box) to obtain consent. The user may indicate consent through pre-selected configuration options, modes, or selectable user interface toggles, with appropriate reporting to the user when the agent detects an error. Agent developers should not ignore usability issues when designing error recovery behavior.
· Protocol designers should provide enough information about an error condition so that an agent can address the error condition. For instance, an HTTP 404 message [skw18] (not found) is useful because it allows user agents to present relevant information to users, enabling them to contact the representation provider in case of problems.
· Experience with the cost of building a user agent to handle the diverse forms of ill-formed HTML content convinced the designers of the XML specification to require that agents fail upon encountering ill-formed content. Because users are unlikely to tolerate such failures, this design choice has pressured all parties into respecting XML's constraints, to the benefit of all.
· An agent that encounters unrecognized content may handle it in a number of ways, including by considering it an error; see also the section on extensibility and versioning .
· Error behavior that is appropriate for a person may not be appropriate for software. People are capable of exercising judgement in ways that software applications generally cannot. An informal error response may suffice for a person but not for a processor.
The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the syntax, semantics, and sequence [skw19] of the messages interchanged. Protocols designed to be resilient in the face of widely varying environments have helped the Web scale and have facilitated communication across multiple trust boundaries. Traditional application programming interfaces ( APIs ) do not always take these constraints into account, nor should they be required to. One effect of protocol-based design is that the technology shared among agents often lasts longer than the agents themselves[skw20] .
It is common for programmers working with the Web to write code that generates and parses these messages directly. It is less common, but not unusual, for end users to have direct exposure to these messages. It is often desirable to provide users with access to format and protocol details: allowing them to " view source ," whereby they may gain expertise in the workings of the underlying system.
In order to communicate internally, a community agrees (to a reasonable extent) on a set of terms and their meanings. [skw21] One design goal for the Web, from its inception, has been to create a global community in which any party can share information with any other party To achieve this goal, the Web makes use of a single global identification mechanism[skw22] . The global scope promotes large-scale "network effects": the value of an identifier increases the more it is used[skw23] (e.g., the more it is used in hypertext links ).
The choice of syntax for global identifiers is somewhat arbitrary; what is important is their global scope. The Uniform Resource Identifier ([ URI ], currently being revised) mechanism [skw24] has been successfully deployed since the creation of the Web. There are substantial benefits to participating in the existing network of URIs, including linking, bookmarking, caching, and indexing by search engines. A resource should be assigned a URI if another party might reasonably want to link [skw25] to it, make or refute assertions about it, retrieve or cache a representation of it, include all or part of it by reference into another representation, annotate it, or perform other operations on it. Software developers should expect that it will prove useful to be able to share a URI across applications, even if that utility is not initially evident. The TAG finding " URIs, Addressability, and the use of HTTP GET and POST " discusses additional benefits and considerations of URI addressability.
Other mechanisms[skw27] for identifying resources (see the section on future directions for identifiers ) may expand the Web as we know it today. However, there are substantial costs to creating a new identification mechanism that has the same properties as URIs.
To keep communication costs down, by design a URI identifies one resource. Since the scope of a URI is global, the resource identified by a URI does not depend on the context in which the URI appears (see also the section about indirect identification ).[skw28]
Just as one might wish to refer to a person by different names (by full name, first name only, sports nickname, romantic nickname, and so forth), Web architecture allows the assignment[skw29] of more than one URI to a resource. URIs that identify the same resource are called URI aliases The section on URI aliases discusses some of the potential costs of creating multiple URIs for the same resource.
The following sections address other questions about the relationship between URIs and resources, including:
· Who determines what resource a URI identifies? See the section on URI ownership .
· Since more than one URI can identify the same resource, how do I know which URIs identify the same resource? See in particular the sections on URI comparison and assertions that two URIs identify the same resource .
· Are there resources that are not identified by any URI? In a system where the only resource identification mechanism is the URI, the question is only of philosophical interest (similarly, if a tree falls in the forest and nobody is around to hear it, does it make a sound?). [skw30] The advent of other resource identification mechanisms may change the nature of this question and answer.
The most straightforward way of
establishing that two parties are referring to the same resource is to compare,
character-by-character, the URIs
they are using. Two URIs that are identical (character
for character) refer to the same resource. Because Web architecture allows the
assignment of more than one URI to a resource, two URIs that are not character
for character identical can still refer to the same resource (i.e., they do not
necessarily refer to different resources). There is generally a higher
computational cost to determine that two different URIs refer to the same
To reduce the risk of a false
negative (i.e., an incorrect conclusion that two URIs do not refer to the same
resource) or a false positive (i.e., an incorrect conclusion that two URIs do
refer to the same resource), certain specifications
tests in addition to character-by-character comparison. For example, for
"http" URIs, the authority component (the part after "//"
and before the next "/") is defined to be case-insensitive. Thus, the
"http" URI specification licenses
applications to conclude that
authority components in two "http" URIs are equivalent when those
strings are character-by-character equivalent or differ only by case. Agents
that reach conclusions based on comparisons that are not licensed by relevant specifications take responsibility for any problems
that result. Section 6 of [ URI ] provides more information about comparing URIs and reducing the
risk of false negatives and positives.[skw31]
See the section below on
approaches other than string comparison that allow different
to assert that two URIs identify the same resource .
Although there are benefits
(such as naming flexibility) to URI aliases, there are also costs. For example,
more than one URI for a
resource undermines the network effect. URI aliases can also raise the cost or
may even make it impossible for software to determine by following
specifications that the URIs identify the same resource. URI producers should
thus be conservative about the number of different URIs they produce
the same resource.
URI consumers also have a role in ensuring URI consistency. For instance, when transcribing a URI, agents should not gratuitously percent-encode characters. The term "character" refers to URI characters as defined in section 2 of [ URI ]; percent-encoding is discussed in section 2.1 of that specification.[skw33]
When a URI alias does become
common currency, the URI owner should use protocol techniques such as server-side
two resources. The community benefits when the URI owner supports both the
"official" URI and the alias.
As discussed above, a URI identifies[skw35] one resource. At times, agents may intentionally or unintentionally use a URI to identify different resources. URI overloading refers to the use of one URI to refer directly to more than one resource. Overloading often imposes a cost in communication due to the effort required to resolve ambiguities.
Suppose, for example, that one organization makes use of a URI to refer to the movie "The Sting", and another organization uses the same URI to refer to a discussion forum about "The Sting." This overloading can create confusion about what the URI identifies, undermining the value of the URI. If one wanted to talk about the creation date of the resource identified by the URI, for instance, it would not be clear whether this meant "when the movie created" or "when the discussion forum about the movie was created."
The section below on URI ownership examines approaches for establishing the authoritative source of information about what resource a URI identifies.
Listening to a news broadcast, one might hear a report on Britain that begins, "Today, 10 Downing Street announced a series of new economic measures." Generally, "10 Downing Street" identifies the official residence of Britain's Prime Minister. In this context, the news reporter is using it (as English rhetoric allows) to indirectly identify the British government. Similarly, URIs identify resources, but they can also be used in many constructs to indirectly identify arbitrary entities. Certain properties [skw37] of URIs make them appealing as general-purpose identifiers. Local policy establishes what they indirectly identify.[skw38]
For example, the URI
"mailto:email@example.com" identifies an Internet mailbox (as
by the "mailto"
URI scheme). Suppose this particular URI identifies Nadia's Internet mailbox.
The organizers of a conference attended by Nadia might use
"mailto:firstname.lastname@example.org" to refer indirectly to her (e.g., using
the URI as a database key in their database of conference participants).
To avoid URI overloading , it is important to reduce the risk that different agents will unintentionally (or intentionally) create [skw40] the same URI (i.e., sequence of characters). URI scheme specifications can help reduce this risk, and commonly do so through the hierarchical delegation of authority. This approach, exemplified by the "http" and "mailto" schemes, allows the assignment of a part of URI space to one party, who may, in turn, delegate management of pieces of that space to other parties[skw41] .
It is thus useful for a URI scheme to establish a unique relationship [skw42] between a social entity [skw43] and a URI; this is the case for the "http", "mailto", "mid", and "cid" schemes, for example. This relationship is called URI ownership . In this document, the phrase "authority responsible for domain X" indicates that the same entity owns those URIs where the authority component is domain X. This document does not address how the benefits and responsibilities of URI ownership may be delegated to other parties, such as to a server manager or to someone who has been delegated part of the URI space on a given Web server.
The approach taken for the "http" URI scheme follows the pattern whereby the Internet community delegates authority, via the IANA URI scheme registry [ IANASchemes ] and the DNS, over a set of URIs with a common prefix to one particular owner. One consequence of this approach is the Web's heavy reliance on the central DNS registry[skw44] .
A URI owner may, upon request, provide representations of the resource identified by the URI. For example, when a URI owner uses the HTTP protocol to provide those representations, the HTTP origin server (defined in [ RFC2616 ]) is the software agent acting on behalf of the URI owner to provide the authoritative representations for the resource identified by that URI. The owner is also responsible for accepting or rejecting requests to modify the resource identified by that URI, for example, by configuring a server to accept or reject HTTP PUT data based on Internet media type, validity constraints, or other constraints.
Recall that the Web architecture allows different URI owners to create URI aliases . This means that multiple parties may provide representations of the same resource, depending on which URI is used for interaction. A URI owner's rights extend only to the representations served for requests given that URI.
There are social expectations for responsible representation management by URI owners, discussed below. Additional social implications of URI ownership are not discussed here. However, the success or failure of these different approaches depends on the extent to which there is consensus in the Internet community on abiding by the defining specifications.[skw45]
In the URI "http://weather.example.com/", the "http" that appears before the colon (":") names a URI scheme. Each URI scheme has a specification that explains how identifiers are assigned within that scheme. The URI syntax is thus a federated and extensible naming mechanism wherein each scheme's specification may further restrict the syntax and semantics of identifiers within that scheme.
Examples of URIs from various schemes include:
While the Web architecture allows the definition of new schemes, introducing a new scheme is costly. Many aspects of URI processing are scheme-dependent, and a significant amount of deployed software already processes URIs of well-known schemes. Introducing a new URI scheme requires the development and deployment not only of client software to handle the scheme, but also of ancillary agents such as gateways, proxies, and caches. See [ RFC2718 ] for other considerations and costs related to URI scheme design.
Because of these costs, if a URI scheme exists that meets the needs of an application, designers should use it rather than invent one.
Consider our travel scenario : should the agent providing information about the weather in Oaxaca register a new URI scheme "weather" for the identification of resources related to the weather? They might then publish URIs such as "weather://travel.example.com/oaxaca". When a software agent dereferences such a URI, if what really happens is that HTTP GET is invoked to retrieve a representation of the resource, then an "http" URI would have sufficed.
If the motivation behind registering a new scheme is to allow a software agent to launch a particular application when retrieving a representation, such dispatching can be accomplished at lower expense via Internet media types. When designing a new data format, the appropriate mechanism to promote its deployment on the Web is the Internet media type. Media types also provide a means for building new information space applications , described below.
Note that even if an agent cannot process representation data in an unknown format, it can at least retrieve it. The data may contain enough information to allow a user or user agent to make some use of it. When an agent does not handle a new URI scheme, it cannot retrieve a representation.
The Internet Assigned Numbers Authority ( IANA ) maintains a registry [ IANASchemes ] of mappings between URI scheme names and scheme specifications. For instance, the IANA registry indicates that the "http" scheme is defined in [ RFC2616 ]. The process for registering a new URI scheme is defined in [ RFC2717 ].
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 beyond URI comparison; the network effect is lost.
Note: Some URI scheme specifications (such as the "ftp" URI scheme specification) use the term "designate" where the current document uses "identify."
It is tempting to guess the nature of a resource by inspection of a URI that identifies it. However, the Web is designed so that agents communicate resource information state through representations , not identifiers. In general, one cannot determine the Internet media type of representations of a resource by inspecting a URI for that resource. For example, the ".html" at the end of "http://example.com/page.html" provides no guarantee that representations of the identified resource will be served with the Internet media type "text/html". The HTTP protocol does not constrain the Internet media type based on the path component of the URI; the URI owner is free to configure the server to return a representation using PNG or any other data format.
Resource state may evolve over time. Requiring a URI owner to publish a new URI for each change in resource state would lead to a significant number of broken links. For robustness, Web architecture promotes independence between an identifier and the identified resource.
The example URI used in the travel scenario ("http://weather.example.com/oaxaca") suggests that the identified resource has something to do with the weather in Oaxaca. A site reporting the weather in Oaxaca could just as easily be identified by the URI "http://vjc.example.com/315". And the URI "http://weather.example.com/vancouver" might identify the resource "my photo album."
On the other hand, the URI "mailto:email@example.com" indicates that the URI refers to a mailbox. The "mailto" URI scheme specification authorizes agents to infer that URIs of this form identify Internet mailboxes.[skw48]
In some cases, relevant technical specifications license URI assignment authorities to publish assignment policies. For more information about URI opacity, see TAG issue metaDataInURI-31 .
The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations. The terms "primary resource" and "secondary resource" are defined in section 3.5 of [ URI ].
The interpretation of fragment identifiers is discussed in the section on media types and fragment identifier semantics .
There remain open questions regarding identifiers on the Web. The following sections identify a few areas of future work in the Web community.
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.
Communication between agents over a network about resources involves URIs, messages, and data. The Web's protocols (including HTTP, FTP, SOAP, NNTP, and SMTP) are based on the exchange of messages. A message may include data as well as metadata about the resource (such as the "Alternates" and "Vary" HTTP headers), the message data, and the message itself (such as the "Transfer-encoding" HTTP header). A message may even include metadata about the message metadata (for message-integrity checks, for instance). Two important classes of message are those that request a representation of an Information Resource , and those that return the result of such a request.
This section describes the architectural principles and constraints regarding interactions between agents, 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. The fact that the Web is a highly distributed system affects architectural constraints and assumptions about interactions.
The term Information Resource refers to the class of resources having information state — state that can be represented as octets. A representation of information state consists logically of two parts: data (expressed in one or more formats used separately or in combination) and metadata (such as the Internet media type of the data).
The Information Resource provides the foundation for the familiar hypertext Web, where agents use representations to modify as well as retrieve information state. Much of this document describes architecture specific to Information Resources. For instance, the techniques of caching and content negotiation , and the social processes of publishing, apply to Information Resources.
Agents may use a URI to access the referenced resource; this is called dereferencing the URI . Access may take many forms, including retrieving a representation of the resource (for instance, by using HTTP GET or HEAD), adding or modifying a representation of the resource (for instance, by using HTTP POST or PUT, which in some cases may change the actual state of the resource if the submitted representations are interpreted as instructions to that end), and deleting some or all representations of the resource (for instance, by using HTTP DELETE, which in some cases may result in the deletion of the resource itself).
There may be more than one way to access a resource for a given URI; application context determines which access mechanism an agent uses. For instance, a browser might use HTTP GET to retrieve a representation of a resource, whereas a link checker might use HTTP HEAD on the same URI simply to establish whether a representation is available. Some URI schemes set expectations about available access mechanisms, others (such as the URN scheme [ RFC 2141 ]) do not. Section 1.2.2 of [ URI ] discusses the separation of identification and interaction in more detail. For more information about relationships between multiple access mechanisms and URI addressability, see the TAG finding " URIs, Addressability, and the use of HTTP GET and POST " .
Although many URI schemes are named after protocols, this does not imply that use of such a URI will necessarily result in access to the resource via the named protocol. Even when an agent uses a URI to retrieve a representation, that access might be through gateways, proxies, caches, and name resolution services that are independent of the protocol associated with the scheme name.
Dereferencing a URI generally involves a succession of steps as described in multiple specifications and implemented by the agent. The following example illustrates the series of specifications that are involved when a user instructs a user agent to follow a hypertext link that is part of an SVG document. In this example, the URI is "http://weather.example.com/oaxaca" and the application context calls for the user agent to retrieve and render a representation of the identified resource.
Since the URI is part
of a hypertext link in an SVG document, the first relevant specification is the
SVG 1.1 Recommendation [ SVG11
17.1 of this specification imports the link semantics defined in XLink 1.0
[ XLink10 ]: "The remote resource (the destination for the
link) is defined by a URI specified by the XLink
href attribute on the '
' element." The SVG specification goes on to state that interpretation of
a element involves retrieving a
representation of a resource, identified by the
href attribute in the XLink namespace: "By activating these
links (by clicking with the mouse, through keyboard input, voice commands,
etc.), users may visit these resources."
The XLink 1.0 [ XLink10
] specification, which defines the
attribute in section 5.4, states that "The value of the href attribute
must be a URI reference as defined in [IETF RFC 2396], or must result in a URI
reference after the escaping procedure described below is applied."
3. The URI specification [ URI ] states that "Each URI begins with a scheme name that refers to a specification for assigning identifiers within that scheme." The URI scheme name in this example is "http".
5. In this SVG context, the agent constructs an HTTP GET request (per section 9.3 of [ RFC2616 ]) to retrieve the representation.
6. Section 6 of [ RFC2616 ] defines how the server constructs a corresponding response message, including the 'Content-Type' field.
7. Section 1.4 of [ RFC2616 ] states "HTTP communication usually takes place over TCP/IP connections." This example does not address that step in the process, or other steps such as Domain Name System ( DNS ) resolution.
8. The agent interprets the returned representation according to the data format specification that corresponds to the representation's Internet Media Type (the value of the HTTP 'Content-Type') in the relevant IANA registry [ MEDIATYPEREG ].
Precisely which representation(s) are retrieved depends on a number of factors, including:
1. Whether the URI owner makes available any representations at all;
2. Whether the agent making the request has access privileges for those representations (see the section on linking and access control );
3. If the URI owner has provided more than one representation (in different formats such as HTML, PNG, or RDF; in different languages such as English and Spanish; or transformed dynamically according to the hardware or software capabilities of the recipient), the resulting representation may depend on negotiation between the user agent and server.
4. The time of the request; information changes over time, and so representations of that information are also likely to change.
Note also that the choice and expressive power of a format can affect how precisely a representation provider communicates resource state. The use of natural language to communicate information may lead to ambiguity about what the associated resource is, which in turn can lead to URI overloading .
The Internet media type [ RFC2046 ]) of a representation determines which data format specification(s) provide the authoritative interpretation of the representation data (including fragment identifier syntax and semantics , if any). The IANA registry [ MEDIATYPEREG ] maps media types to data formats . The TAG finding " Internet media type registration, consistency of use " provides more information to W3C groups about media type registration.
Internet media type mechanism does have its limitations. For instance, media type strings do not support versioning or other parameters. The TAG issue mediaTypeManagement-45 concerns the appropriate level of granularity of the media type mechanism.
Per [ URI ], given a URI "U#F", and a representation retrieved by dereferencing URI "U" (which is authoritative), the ( secondary ) resource identified by "U#F" is determined by interpreting "F" according to the specification associated with the Internet media type of the representation data. Thus, in the case of Dirk and Nadia, the authoritative interpretation of the fragment identifier is given by the SVG specification, not the XHTML specification (i.e., the context where the URI appears).
The semantics of a 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 potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and, effectively, unconstrained. Fragment identifier semantics are orthogonal to URI schemes and thus cannot be redefined by URI scheme specifications.
Interpretation of the fragment identifier 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.
As with any URI, use of a fragment identifier component does not imply that a retrieval action will take place. A URI with a fragment identifier 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 URIs with fragment identifiers without a retrieval action. Parties that draw conclusions about the interpretation of a fragment identifier based solely on a syntactic analysis of all or part of a URI do so at their own risk; such interpretations are not authoritative because they are not licensed by specification (specifically [ URI ]).
Please note the following about primary and secondary resources:
1. A resource may be both a primary and secondary resource since more than one URI may identify the resource.
2. One cannot carry out an HTTP POST operation using a URI that identifies a secondary resource.
Content negotiation refers to the practice of making available multiple representations via the same URI. Negotiation between the requesting agent and the server determines which representation is served (usually with the goal of serving the "best" representation a receiving agent can process). HTTP is an example of a protocol that enables representation providers to use content negotiation.
Individual data formats may define their own restrictions on, or structure within, the fragment identifier syntax for specifying different types of subsets, views, or external references that are identifiable as secondary resources by that media type. Therefore, representation providers must manage content negotiation carefully when used with a URI that contains a fragment identifier. Consider an example where the owner of the URI "http://weather.example.com/oaxaca/map#zicatela" uses content negotiation to serve two representations of the identified resource. Three situations can arise:
1. The interpretation of "zicatela" is defined consistently by both data format specifications. The representation provider decides when definitions of fragment identifier semantics are are sufficiently consistent.
2. The interpretation of "zicatela" is defined inconsistently by the data format specifications.
3. The interpretation of "zicatela" is defined in one data format specification but not the other.
The first situation — consistent semantics — poses no problem.
The second case is a server management error: representation providers must not use content negotiation to serve representation formats that have inconsistent fragment identifier semantics. This situation also leads to URI overloading .
The third case is not a server management error. It is a means by which the Web can grow. Because the Web is a distributed system in which formats and agents are deployed in a non-uniform manner, Web architecture does not constrain authors to only use "lowest common denominator" formats. Content authors may take advantage of new data formats while still ensuring reasonable backward-compatibility for agents that do not yet implement them.
In case three, behavior by the receiving agent should vary depending on whether the negotiated format defines fragment identifier semantics. When a received data format does not define fragment identifier semantics, the agent should not perform silent error recovery unless the user has given consent; see [ CUAP ] for additional suggested agent behavior in this case.
See related TAG issue RDFinXHTML-35 .
Successful communication between two parties depends on a reasonably shared understanding of the semantics of exchanged messages, both data and metadata. At times, there may be inconsistencies between a message sender's data and metadata. For instance, examples that have been observed in practice of inconsistencies between representation data and metadata include:
The actual character
encoding of a representation (e.g., "iso-8859-1", specified by the
encoding attribute in an XML declaration) is
inconsistent with the charset parameter in the representation metadata (e.g.,
"utf-8", specified by the 'Content-Type' field in an HTTP header).
· The namespace of the root element of XML representation data (e.g., as specified by the "xmlns" attribute) is inconsistent with the value of the 'Content-Type' field in an HTTP header.
On the other hand, there is no inconsistency in serving HTML content with the media type "text/plain", for example, as this combination is licensed by specification. Receiving agents should detect protocol inconsistencies and perform proper error recovery .
Thus, for example, if the parties responsible for "weather.example.com" mistakenly label the satellite photo of Oaxaca as "image/gif" instead of "image/jpeg", and if Nadia's browser detects a problem, Nadia's browser must not ignore the problem (e.g., by simply rendering the JPEG image) without Nadia's consent. Nadia's browser can notify Nadia of the problem or notify Nadia and take corrective action.
Furthermore, representation providers can help reduce the risk of inconsistencies through careful assignment of representation metadata (especially that which applies across representations). The section on media types for XML presents an example of reducing the risk of error by providing no metadata about character encoding when serving XML.
The TAG finding " Client handling of MIME headers " discusses in more detail the handling of this type of inconsistency.
Nadia's retrieval of weather information (an example of a read-only query or lookup) qualifies as a "safe" interaction; a safe interaction is one where the agent does not incur any obligation beyond the interaction. An agent may incur an obligation through other means (such as by signing a contract). If an agent does not have an obligation before a safe interaction, it does not have that obligation afterwards.
Other Web interactions resemble orders more than queries. These unsafe interactions may cause a change to the state of a resource and the user may be held responsible for the consequences of these interactions. Unsafe interactions include subscribing to a newsletter, posting to a list, or modifying a database. Note: In this context, the word "unsafe" does not necessarily mean "dangerous"; the term "safe" is used in section 9.1.1 of [ RFC2616 ] and "unsafe" is the natural opposite.
Safe interactions are important because these are interactions where users can browse with confidence and where agents (including search engines and browsers that pre-cache data for the user) can follow links safely. Users (or agents acting on their behalf) do not commit themselves to anything by querying a resource or following a link.
For instance, it is incorrect to publish a link that, when followed, subscribes a user to a mailing list. Remember that search engines may follow such links.
For more information about safe and unsafe operations using HTTP GET and POST, and handling security concerns around the use of HTTP GET, see the TAG finding " URIs, Addressability, and the use of HTTP GET and POST " .
Transaction requests and results are valuable resources, and like all valuable resources, it is useful to be able to refer to them with a persistent URI . However, in practice, Nadia cannot bookmark her commitment to pay (expressed via the POST request) or the airline company's acknowledgment and commitment to provide her with a flight (expressed via the response to the POST).
There are ways to improve the situation. For transaction requests, user agents can provide an interface for managing transactions where the user agent has incurred an obligation on behalf of the user. For transaction results, HTTP allows representation providers to assign a URI to the results of an HTTP POST request using the "Content-Location" header (described in section 14.14 of [ RFC2616 ]).
A URI owner may supply zero or more authoritative representations of the resource identified by that URI. There is a benefit to the community in providing representations.
For example, owners of XML namespace URIs should use them to identify a namespace document .
As is the case with many human interactions, confidence in interactions via the Web depends on stability and predictability. For an Information Resource , persistence generally depends directly on the consistency of information conveyed by a series of representations. The representation provider decides when representations are sufficiently consistent (although that determination generally takes user expectations into account).
Although persistence in this case is observable as a result of representation retrieval, the term URI persistence is used to describe the desirable property that, once assigned to a resource, a URI should continue indefinitely to refer to that resource.
URI persistence is a matter of policy and commitment on the part of the URI owner . The choice of a particular URI scheme provides no guarantee that those URIs will be persistent or that they will not be persistent.
HTTP [ RFC2616 ] has been designed to help manage URI persistence. For example, HTTP redirection (using the 3xx response codes) permits servers to tell an agent that further action needs to be taken by the agent in order to fulfill the request (for example, the resource has been assigned a new URI).
In addition, content negotiation also promotes consistency, as a site manager is not required to define new URIs when adding support for a new format specification. Protocols that do not support content negotiation (such as FTP) require a new identifier when a new data format is introduced. Improper use of content negotiation can lead to inconsistent representations.
For more discussion about URI persistence, see [ Cool ].
It is reasonable to limit access to a resource (for commercial or security reasons, for example), but it is unreasonable to prohibit others from merely identifying the resource.
As an analogy: The owners of a building might have a policy that the public may only enter the building via the main front door, and only during business hours. People who work in the building and who make deliveries to it might use other doors as appropriate. Such a policy would be enforced by a combination of security personnel and mechanical devices such as locks and pass-cards. One would not enforce this policy by hiding some of the building entrances, nor by requesting legislation requiring the use of the front door and forbidding anyone to reveal the fact that there are other doors to the building.
The Web provides several mechanisms to control access to resources; these mechanisms do not rely on hiding or suppressing URIs for those resources. For more information, see the TAG finding " 'Deep Linking' in the World Wide Web " .
There remain open questions regarding Web interactions. The TAG expects future versions of this document to address in more detail the relationship between the architecture described herein, Web Services , peer-to-peer systems, instant messaging systems (such as [ XMPP ]), and voice-over-IP (such as RTSP [ RFC2326 ]).
A data format (including XHTML, RDF/XML, SMIL, XLink, CSS, and PNG) specifies the interpretation of representation data. The first data format used on the Web was HTML. Since then, data formats have grown in number. The Web architecture does not constrain which data formats content providers can use. This flexibility is important because there is constant evolution in applications, resulting in new data formats and refinements of existing formats. Although the Web architecture allows for the deployment of new data formats, the creation and deployment of new formats (and agents able to handle them) is expensive. Thus, before inventing a new data format (or "meta" format such as XML), designers should carefully consider re-using one that is already available.
For a data format to be usefully interoperable between two parties, the parties must agree (to a reasonable extent) about its syntax and semantics. Shared understanding of a data format promotes interoperability but does not imply constraints on usage; for instance, a data sender cannot count on being able to constrain the behavior of a data receiver.
Below we describe some characteristics of a data format that facilitate integration into the Web architecture. This document does not address generally beneficial characteristics of a specification such as readability, simplicity, attention to programmer goals, attention to user needs, accessibility, nor internationalization. The section on architectural specifications includes references to additional format specification guidelines.
Binary data formats are those in which portions of the data are encoded for direct use by computer processors, for example thirty-two bit little-endian two's-complement and sixty-four bit IEEE double-precision floating-point. The portions of data so represented include numeric values, pointers, and compressed data of all sorts.
A textual data format is one in which the data is specified as a sequence of characters. HTML, Internet e-mail, and all XML-based formats are textual. Increasingly, internationalized textual data formats refer to the Unicode repertoire [ UNICODE ] for character definitions.
In principle, all data can be represented using textual formats.
The trade-offs between binary and textual data formats are complex and application-dependent. Binary formats can be substantially more compact, particularly for complex pointer-rich data structures. Also, they can be consumed more rapidly by agents in those cases where they can be loaded into memory and used with little or no conversion.
Textual formats are usually more portable and interoperable. Textual formats also have the considerable advantage that they can be directly read by human beings (and understood, given sufficient documentation). This can simplify the tasks of creating and maintaining software, and allow the direct intervention of humans in the processing chain without recourse to tools more complex than the ubiquitous text editor. Finally, it simplifies the necessary human task of learning about new data formats; this is called the "view source" effect .
It is important to emphasize that intuition as to such matters as data size and processing speed is not a reliable guide in data format design; quantitative studies are essential to a correct understanding of the trade-offs. Therefore, designers of a data format specification should make a considered choice between binary and textual format design.
Note: Text (i.e., a sequence of characters from a repertoire) is distinct from serving data with a media type beginning with "text/". Although XML-based formats are textual, many XML-based formats do not consist primarily of phrases in natural language. See the section on media types for XML for issues that arise when "text/" is used in conjunction with an XML-based format.
See TAG issue binaryXML-30 .
Extensibility and versioning are strategies to help manage the natural evolution of information on the Web and technologies used to represent that information.
There is typically a (long) transition period during which multiple versions of a format, protocol, or agent are simultaneously in use.
Dirk and Nadia have chosen a particular namespace change policy that allows them to avoid changing the namespace name whenever they make changes that do not affect conformance of deployed content and software. They might have chosen a different policy, for example that any new element or attribute has to belong to a namespace other than the original one. Whatever the chosen policy, it should set clear expectations for users of the format.
As an example of a change policy designed to reflect the variable stability of a namespace, consider the W3C namespace policy for documents on the W3C Recommendation track. The policy sets expectations that the Working Group responsible for the namespace may modify it in any way until a certain point in the process ("Candidate Recommendation") at which point W3C constrains the set of possible changes to the namespace in order to promote stable implementations.
Note that since namespace names are URIs, the owner of a namespace URI has the authority to decide the namespace change policy.
Designers can facilitate the transition process by making careful choices about extensibility during the design of a language or protocol specification.
Application needs determine the most appropriate extension strategy for a specification. For example, applications designed to operate in closed environments may allow specification designers to define a versioning strategy that would be impractical at the scale of the Web.
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 for the language to allow either form of extension, but to distinguish explicitly between them in the syntax.
Additional strategies include prompting the user for more input and automatically retrieving data from available links. More complex strategies are also possible, including mixing strategies. For instance, a language can include mechanisms for overriding standard behavior. Thus, a data format can specify "must ignore" semantics but also allow for extensions that override that semantics in light of application needs (for instance, with "must understand" semantics for a particular extension).
Extensibility is not free. Providing hooks for extensibility is one of many requirements to be factored into the costs of language design. Experience suggests that the long term benefits of extensibility generally outweigh the costs.
Many modern data format include mechanisms for composition. For example:
· It is possible to embed text comments in some image formats, such as JPEG/JFIF. Although these comments are embedded in the containing data, they have little or no effect on the display of the 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.
· The semantics of combining RDF documents containing multiple vocabularies is well-defined.
These relationships can be mixed and nested arbitrarily. In principle, a SOAP message can contain an SVG image that contains an RDF comment which refers to a vocabulary of terms for describing the image.
Note however, that 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 of an element has on the element's ancestors, siblings, and descendants.
The Web is a heterogeneous environment where a wide variety of agents provide access to content to users with a wide variety of capabilities. It is good practice for authors to create content that can reach the widest possible audience, including users with graphical desktop computers, hand-held devices and mobile phones, users with disabilities who may require speech synthesizers, and devices not yet imagined. Furthermore, authors cannot predict in some cases how an agent will display or process their content. Experience shows that the separation of content, presentation, and interaction promotes the reuse and device-independence of content; his follows from the principle of orthogonal specifications . For more information about principles of device-independence, see [ DIPRINCIPLES ].
Note that when content, presentation, and interaction are separated by design, agents need to recombine them. There is a recombination spectrum, with "client does all" at one end and "server does all" at the other. There are advantages to each: recombination on the server allows the server to send out generally smaller amounts of data that can be tailored to specific devices (such as mobile phones). However, such data will not be readily reusable by other clients and may not allow client-side agents to perform useful tasks unanticipated by the author. When a client does the work of recombination, content is likely to be more reusable by a broader audience and more robust. However, such data may be of greater size and may require more computation by the client.
Of course, it may not always be desirable to reach the widest possible audience. Designers should consider appropriate technologies for limiting the audience. For instance digital signature technology, access control , and other technologies are appropriate for controlling access to content.
Some data formats are designed to describe presentation (including SVG and XSL Formatting Objects). Data formats such as these demonstrate that one can only separate content from presentation (or interaction) so far; at some point it becomes necessary to talk about presentation. Per the principle of orthogonal specifications these data formats should only address presentation issues.
A defining characteristic of the
Web is that it allows embedded references to other resources via URIs. The
simplicity of creating links using absolute URIs (
href="http://www.example.com/foo"> ) and relative URI references (
<a href="foo"> and
<a href="foo#anchor"> ) is partly (perhaps largely)
responsible for the birth of the hypertext Web as we know it today.
When one resource (representation) refers to another resource with a URI, this constitutes a link between the two resources. Additional metadata may also form part of the link (see [ XLink10 ], for example).
Formats that allow content authors to use URIs instead of local identifiers promote the network effect: the value of these formats grows with the size of the deployed Web.
What agents do with a hypertext link is not constrained by Web architecture and may depend on application context. Users of hypertext links expect to be able to navigate links among representations.
Data formats that do not allow content authors to create hypertext links lead to the creation of "terminal nodes" on the Web.
Links are commonly expressed
references (defined in section 4.2 of [ URI
]), which may be combined with a base URI to yield a usable URI. Section 5.1 of
] explains different mechanisms for establishing a base URI for a resource and
establishes a precedence among the various mechanisms. For instance, the base
URI may be a URI for the resource, or specified in a representation (see the
base elements provided by HTML and XML, and the HTTP
'Content-Location' header). See also the section on links
in XML .
Agents resolve a URI reference before using the resulting URI to interact with another agent. URI references help in content 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 the associated resource.
Many data formats are XML-based , that is to say they conform to the syntax rules defined in the XML specification [XML10] . This section discusses issues that are specific to such formats. Anyone seeking guidance in this area is urged to consult the "Guidelines For the Use of XML in IETF Protocols" [IETFXML] , which contains a thorough discussion of the considerations that govern whether or not XML ought to be used, as well as specific guidelines on how it ought to be used. While it is directed at Internet applications with specific reference to protocols, the discussion is generally applicable to Web scenarios as well.
The discussion here should be seen as ancillary to the content of [IETFXML] . Refer also to "XML Accessibility Guidelines" [XAG] for help designing XML formats that lower barriers to Web accessibility for people with disabilities.
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 a hierarchical structure.
2. The data's usefulness should outlive the tools currently used to process it (though obviously XML can be used for short-term needs as well).
3. Ability to support internationalization in a self-describing way that makes confusion over coding options unlikely.
4. Early detection of 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 format with other XML-encoded formats.
Sophisticated linking mechanisms have been invented for XML formats. XPointer allows links to address content that does not have an explicit, named anchor. XLink is an appropriate specification for representing links in hypertext XML applications. 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.
Designers of XML-based formats should consider using XLink and, for defining fragment identifier syntax, using the XPointer framework and XPointer element() Schemes.
See TAG issue xlinkScope-23 .
The purpose of an XML namespace
(defined in [ XMLNS ]) is to allow the deployment of XML vocabularies (in
which element and attribute names are defined) in a global environment and to
reduce the risk of name collisions in a given document when vocabularies are combined.
For example, the MathML and SVG specifications both define the
set element. Although XML data from different formats such as
MathML and SVG can be combined in a single document, in this case there could
be ambiguity about which
set element was intended. XML namespaces
reduce the risk of name collisions by taking advantage of existing mechanisms
for allocating globally scoped names: the URI system (see also the section on URI ownership ). When using XML namespaces, each local name in
an XML vocabulary is paired with a URI (called the namespace URI) to
distinguish the local name from local names in other vocabularies. All of the
globally grounded terms in an XML namespace share the same syntactic prefix:
the namespace URI.
The use of URIs confers additional benefits. First, each local name / URI pair can be mapped to another URI, grounding the terms of the vocabulary in the Web. These terms may be important resources and thus it is appropriate to be able to assign URIs to them. One particularly useful mapping in the case of flat namespaces (specified, for example, in [ RDF10 ]) is to combine the namespace URI, a hash ("#"), and the local name, thus creating a URI for a secondary resource (the identified term). Other mappings are likely to be more suitable for hierarchical namespaces; see the related TAG issue abstractComponentRefs-37 .
Designers of XML-based data formats who declare namespaces thus make it possible to reuse those data formats and combine them in novel ways not yet imagined. Failure to declare namespaces makes such re-use more difficult, even impractical in some cases.
Attributes are always scoped by the element on which they appear. An attribute that is "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 context provided by that element.
type attribute from the W3C XML Schema Instance namespace
"http://www.w3.org/2001/XMLSchema-instance" ([ XMLSCHEMA
], section 4.3.2) is an example of a global attribute. It can be used by
authors of any vocabulary to make an assertion in instance data about the type
of the element on which it appears. As a global attribute, it must always be
frame attribute on an HTML table is an example
of a local attribute. There is no value in placing that attribute in a
namespace since the attribute is unlikely to be useful on an element other than
an HTML table.
Applications that rely on DTD processing must impose additional constraints on the use of 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 ].
Another benefit of using URIs to build XML namespaces is that the namespace URI can be used to identify an Information Resource that contains useful information, machine-usable and/or human-usable, about terms in the namespace. This type of Information Resource is called a namespace document . When a namespace URI owner provides a namespace document, it is authoritative for the namespace.
There are many reasons to provide a namespace document. A person might want to:
· understand the purpose of the namespace,
· learn how to use the markup vocabulary in the namespace,
· find out who controls it and associated policies,
· request authority to access schemas or collateral material about it, or
· report a bug or situation that could be considered an error in some collateral material.
A processor might want to:
· retrieve a schema, for validation,
· retrieve a style sheet, for presentation, or
· retrieve ontologies, for making inferences.
In general, there is no established best practice for creating representations of a namespace document; application expectations will influence what data format or formats are used. Application expectations will also influence whether relevant information appears directly in a representation or is referenced from it.
For example, the following are examples of data formats for namespace documents: [ OWL10 ], [ RDDL ], [ XMLSCHEMA ], and [ XHTML11 ]. Each of these formats meets different requirements described above for satisfying the needs of an agent that wants more information about the namespace. Note, however, issues related to fragment identifiers and content negotiation if content negotiation is used.
Section 3 of "Namespaces in XML" [ XMLNS ] 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 the use of QNames as names for XML elements and attributes.
Other specifications, starting with [ XSLT10 ], have employed the idea of using QNames in contexts other than element and attribute names, for example in attribute values and in element content. However, general XML processors cannot reliably recognize QNames as such when they are used in attribute values and in element content; for example, the syntax of QNames overlaps with that of URIs. Experience has also revealed other limitations to QNames, such as losing namespace bindings after XML canonicalization.
For more information, see the TAG finding " Using QNames as Identifiers in Content " .
Because QNames are compact, some specification designers have adopted the same syntax as a means of identifying resources. Though convenient as a shorthand notation, this usage has a cost. There is no single, accepted way to convert a QName into a URI or vice versa. Although QNames are convenient, they do not replace the URI as the identification mechanism of the Web. The use of QNames to identify Web resources without providing a mapping to URIs is inconsistent with Web architecture.
One particularly useful mapping in the case of flat namespaces is to combine the namespace URI, a hash ("#"), and the local name; see the section on XML namespaces for more examples.
Consider the following fragment
section element have what the XML Recommendation
refers to as the ID
foo (i.e., "foo" must not appear
in the surrounding XML document more than once)? One cannot answer this
question by examining the element and its attributes alone. In XML, the quality
of "being an ID" is associated with the type of an attribute, not its
name. Finding the IDs in a document requires additional processing.
document with a processor that recognizes DTD attribute list declarations (in
the external or internal subset) might reveal a declaration that identifies the
name attribute as an ID. Note: This processing is not
necessarily part of validation. A non-validating, DTD-aware processor can
perform ID assignment.
document with a W3C XML schema might reveal an element declaration that
name attribute as an W3C XML Schema
3. In practice, processing the document with another schema language, such as RELAX NG [ RELAXNG ], might reveal the attributes declared to be of ID in the XML Schema sense. Many modern specifications begin processing XML at the Infoset [ 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 ]) may usefully identify the attributes of type ID.
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 a processor might only look in the Infoset and 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 issue xmlIDSemantics-32 .
RFC 3023 defines the Internet media types "application/xml" and "text/xml", and describes a convention whereby XML-based data formats use Internet media types with a "+xml" suffix, for example "image/svg+xml".
These Internet media types create two problems: First, for data identified as "text/*", Web intermediaries are allowed to "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.
Second, representations whose
Internet media types begin with "text/" are required, unless the
charset parameter is specified, to be considered
to be encoded in US-ASCII. Since the syntax of XML is designed to make
documents self-describing, it is good practice to omit the
charset parameter, and since XML is very often
not encoded in US-ASCII, the use of "text/" Internet media types
effectively precludes this good practice.
The section on media types and fragment identifier semantics discusses the interpretation of fragment identifiers. Designers of an XML-based data format specification should define the semantics of fragment identifiers in that format. The XPointer Framework [ XPTRFR ] provides an interoperable starting point.
When the media type 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 such data. The same is true if the assigned media type has the suffix "+xml" (defined in "XML Media Types" [ RFC3023 ]), and the data format specification does not specify fragment identifier semantics. In short, just knowing that content is XML does not provide information about fragment identifier semantics.
Many people assume that the
#abc , when referring to XML data, identifies
the element in the document with the ID "abc". However, there is no
normative support for this assumption.
See TAG issue fragmentInXML-28 .
Because of their role in defining fragment identifier semantics, data formats enable the creation of new applications to make use of the information space infrastructure. The Semantic Web is one such application, built on top of RDF [ RDF10 ]. This document does not discuss the Semantic Web in detail; the TAG expects that future editions of this document will. See the related TAG issue httpRange-14 .
The practice of providing multiple representations available via the same URI. Which representation is served depends on negotiation between the requesting agent and the agent serving the representations.
Access the resource identified by the URI.
An agent repairs an error so that within the system, it is as though the error never occurred.
An agent invokes exceptional behavior because it does not correct the error.
If one language is a subset of another, the latter is called an extended language.
The part of a URI that allows identification of a secondary resource.
A resource that has an information state — state that can be represented as an octet sequence.
A relationship between two resources when one resource (representation) refers to the other resource by means of a URI.
A unit of communication between agents.
The Information Resource identified by an XML Namespace URI
Data and metadata that represents the information state of a resource.
An item of interest in the information space known as the World Wide Web.
Interaction with a resource where an agent does not incur any obligation beyond the interaction.
A resource related to another resource by the following relationship: Given a URI "U#F", and a representation retrieved by dereferencing URI "U", the secondary resource identified by "U#F" is determined by interpreting "F" according to the specification associated with the Internet media type of the representation data.
One language is a subset 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.
Acronym for Uniform Resource Identifier.
Two or more URIs that are character by character different but identify the same resource.
The use of the same URI to refer to more than one resource in the context of Web protocols and formats.
The relationship between assigning agent and URI that is defined by a URI scheme.
The social expectation that once a URI identifies a particular resource, it should continue indefinitely to refer to that resource.
An operational shorthand for a URI.
A global identifier in the context of the World Wide Web.
Interaction with a resource that is not safe interaction.
One type of Web agent; a piece of software acting on behalf of a person.
The result of direct exposure to the underlying protocols which allows users to gain expertise in the workings of a system.
Acronym for World Wide Web.
Shortened form of World Wide Web.
A person or a piece of software acting on the information space on behalf of a person, entity, or process.
An information space in which items of interest are identified by Uniform Resource Identifiers.
One that conforms to the syntax rules defined in the XML specification.
Common Gateway Interface/1.1 Specification . Available at http://hoohoo.ncsa.uiuc.edu/cgi/interface.html.
Common User Agent Problems , K. Dubost, January 2003. This W3C Team Submission is available at http://www.w3.org/TR/cuap.
Cool URIs don't change T. Berners-Lee, W3C, 1998 Available at http://www.w3.org/Provider/Style/URI. Note that the title is somewhat misleading. It is not the URIs that change, it is what they identify.
Knowledge-Domain Interoperability and an Open Hyperdocument System , D. C. Engelbart, June 1990.
IANA's online registry of URI Schemes is available at http://www.iana.org/assignments/uri-schemes.
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 .
XML Information Set (Second Edition) , J. Cowan, R. Tobin, Editors, W3C Recommendation, 4 February 2004, http://www.w3.org/TR/2004/REC-xml-infoset-20040204 . Latest version available at http://www.w3.org/TR/xml-infoset .
IETF Internationalized Resource Identifiers (IRIs) , M. Düaut;rst, M. Suignard, Nov 2002. This IETF Internet Draft is available at http://www.w3.org/International/iri-edit/draft-duerst-iri.html. If this document is no longer available, refer to the home page for Editing 'Internationalized Resource Identifiers (IRIs)' .
IANA's online registry of Internet Media Types is available at http://www.iana.org/assignments/media-types/index.html.
OWL Web Ontology Language Reference , G. Schreiber, M. Dean, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/ . Latest version available at http://www.w3.org/TR/owl-ref/ .
The Platform for Privacy Preferences 1.0 (P3P1.0) Specification , M. Marchiori, Editor, W3C Recommendation, 16 April 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/ . Latest version available at http://www.w3.org/TR/P3P/ .
Resource Directory Description Language (RDDL) , J. Borden, T. Bray, eds., 1 June 2003. This document is available at http://www.tbray.org/tag/rddl/rddl3.html.
Resource Description Framework (RDF) Model and Syntax Specification , O. Lassila, R. R. Swick, Editors, W3C Recommendation, 22 February 1999, http://www.w3.org/TR/1999/REC-rdf-syntax-19990222 . Latest version available at http://www.w3.org/TR/REC-rdf-syntax .
The RELAX NG schema language project.
Representational State Transfer (REST) , Chapter 5 of "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Thesis of R. T. Fielding, 2000. Designers of protocol specifications in particular should invest time in understanding the REST model and the relevance of its principles to a given design. These principles include statelessness, clear assignment of roles to parties, uniform address space, and a limited, uniform set of verbs. Available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.
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.
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.
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.
IETF RFC 2141: URN Syntax , R. Moats, May 1997. Available at http://www.ietf.org/rfc/rfc2141.txt.
IETF RFC 2326: Real Time Streaming Protocol (RTSP) , H. Schulzrinne, A. Rao, R. Lanphier, April 1998. Available at: http://www.ietf.org/rfc/rfc2326.txt.
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.
, R. Petke, I. King, November 1999. Available at http://www.ietf.org/rfc/rfc2717.txt.
SOAP Version 1.2 Part 1: Messaging Framework , M. Hadley, N. Mendelsohn, J. Moreau, H. Frystyk Nielsen, M. Gudgin, Editors, W3C Recommendation, 24 June 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ . Latest version available at http://www.w3.org/TR/soap12-part1/ .
Scalable Vector Graphics (SVG) 1.1 Specification , J. Ferraiolo, 藤沢, D. Jackson, Editors, W3C Recommendation, 14 January 2003, http://www.w3.org/TR/2003/REC-SVG11-20030114/ . Latest version available at http://www.w3.org/TR/SVG11/ .
Uniform Resource Identifiers (URI): Generic Syntax (T. Berners-Lee, R. Fielding, L. Masinter, Eds.) is currently being revised. Citations labeled [ URI ] refer to " Uniform Resource Identifier (URI): Generic Syntax ."
Voice Extensible Markup Language (VoiceXML) Version 2.0 , J. Ferrans, A. Hunt, B. Lucas, B. Porter, K. G. Rehor, S. Tryphonas, S. McGlashan, D. C. Burnett, J. Carter, P. Danielsen, Editors, W3C Recommendation, 16 March 2004, http://www.w3.org/TR/2004/REC-voicexml20-20040316/ . Latest version available at http://www.w3.org/TR/voicexml20 .
XHTML™ 1.1 - Module-based XHTML , M. Altheim, S. McCarron, Editors, W3C Recommendation, 31 May 2001, http://www.w3.org/TR/2001/REC-xhtml11-20010531 . Latest version available at http://www.w3.org/TR/xhtml11/ .
XML Linking Language (XLink) Version 1.0 , S. J. DeRose, E. Maler, D. Orchard, Editors, W3C Recommendation, 27 June 2001, http://www.w3.org/TR/2001/REC-xlink-20010627/ . Latest version available at http://www.w3.org/TR/xlink/ .
Extensible Markup Language (XML) 1.0 (Third Edition) , F. Yergeau, T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, Editors, W3C Recommendation, 4 February 2004, http://www.w3.org/TR/2004/REC-xml-20040204 . Latest version available at http://www.w3.org/TR/REC-xml .
Namespaces in XML 1.1 , A. Layman, R. Tobin, T. Bray, D. Hollander, Editors, W3C Recommendation, 4 February 2004, http://www.w3.org/TR/2004/REC-xml-names11-20040204 . Latest version available at http://www.w3.org/TR/xml-names11/ .
XML Schema Part 1: Structures , H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn, Editors, W3C Recommendation, 2 May 2001, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ . Latest version available at http://www.w3.org/TR/xmlschema-1/ .
The Extensible Messaging and Presence Protocol ( XMPP ) IETF Working Group is developing "an open, XML-based protocol for near real-time extensible messaging and presence. It is the core protocol of the Jabber Instant Messaging and Presence technology..."
XPointer Framework , P. Grosso, E. Maler, J. Marsh, N. Walsh, Editors, W3C Recommendation, 25 March 2003, http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ . Latest version available at http://www.w3.org/TR/xptr-framework/ .
Authoring Tool Accessibility Guidelines 1.0 , J. 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.w3.org/TR/ATAG10 .
Character Model for the World Wide Web 1.0: Fundamentals , T. 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.w3.org/TR/charmod/ .
Device Independence Principles , 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.w3.org/TR/di-princ/ .
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.
QA Specification Guidelines , L. Rosenthal, K. Dubost, D. Hazaël-Massieux, L. Henderson, Editors, W3C Working Draft (work in progress), 2 June 2004, http://www.w3.org/TR/2004/WD-qaframe-spec-20040602/ . Latest version available at http://www.w3.org/TR/qaframe-spec/ .
User Agent Accessibility Guidelines 1.0 , 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/ .
Web Content Accessibility Guidelines 2.0 , 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 available at http://www.w3.org/TR/WCAG20/ .
Web Services Architecture , H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, D. Orchard, D. Booth, Editors, W3C Working Group Note, 11 February 2004, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/ . Latest version available at http://www.w3.org/TR/ws-arch/ .
XML Accessibility Guidelines , D. Dardailler, S. B. Palmer, C. McCathieNevile, Editors, W3C Working Draft (work in progress), 3 October 2002, http://www.w3.org/TR/2002/WD-xag-20021003 . Latest version available at http://www.w3.org/TR/xag .
This document was authored by the W3C Technical Architecture Group which included the following participants: Tim Berners-Lee (co-Chair, W3C), Tim Bray (Antarctica Systems), Dan Connolly (W3C), Paul Cotton (Microsoft Corporation), Roy Fielding (Day Software), Mario Jeckle (Daimler Chrysler), Chris Lilley (W3C), David Orchard (BEA Systems), Norman Walsh (Sun), and Stuart Williams (co-Chair, Hewlett-Packard).
[skw1]This phrase continues to give problems. Link is the problem word here because I believe it is intended to in the sense of a reference or association or named relationship made between resources. Whereas some have taken in it in the sense of a (physical) communications link between resources.
[skw2]Identification in the sense of naming( Pat Hayes D sense)… or identification in the sense of an operational method for retrieving representations (C sense)? I read it in the sense of naming objects in the information space but I don't know whether that is strongly (D) or (C).
[skw3]Up front I'd like to add the "…anything can be a resource" statement - if that is a concensus. I am minde by Pat Hayes comments "So you might want to say that the real definition of
"resource" ought to be anything that can be uniquely *described*
using URIs. Then just being directly identified by a URI is like the
ground case of a potentially very large recursion.
[skw4]Well… the in line examples go outside the bounds of the travel scenario. I don't think it is used throughout.
[skw5]Nadia seems to be inferring information a bout a resource from its name!
[skw6](C) or (D) sense? I can read both.
[skw8]Representations of what? Resources? Resource State? (to some fidelity)
[skw9]Hmmm… this does invite the response… "Oh no it doesn’t!" on both counts J
[skw10](C) and (D) sense problem again. In the (C) sense identification entails a scheme definition that give an operationalised account of how dereference the resource. In the (D) not such account is necessary,although it is useful if the URI c-identifies the thing it denotes (d-identifies).
[skw11]Give an example of such a change.
[skw12]I don't understand what this is trying to say.
[skw13]Informative reference to relevant informational RFC.
[skw14]Do we have any tame computational linguist (eg. Henry) who would endorse these terms or offer us terms that are generally used in the computational linguistic community?
[skw15]I don't think that I quite take this definition as is. Error Recovery involves that use of some strategy that is explicitly aware that an error has occurred. Ie. the continued processing in some sense is a contingency for a possible error condition that has been anticipated. It is not that the error is simply ignored and the agent continues. The continuation (in a recovery situation) is dealing with the fact that the error occurred.
[skw16]Suggest replace "transparent" with "visible".
[skw17]..with URI? (joke)
[skw20]I think I'd make the point that protocols promote interoperability while API's promote application/implementation portability. Both are important. The two become entangled when message content contains scripts or behaviours that the recipient is expected to execute. To be interoperable the script writer has to assume the existence of a run-time environment and may have to probe for the existence of API features in order to be fully interoperable.
[skw21]I'd delete this sentence entirely. It opens up big philosophical questions. "reasonable extent" is also very fuzzy.
[skw22]If this is a reference to URIs then it is a "single global system of identifiers". It is not clear to me that we have a "single global identification mechanism".
[skw23]I'd amend this to "the more it is used consistently.
[skw24]Avoid the 'mechanism' word.
[skw25]Is the sense of 'link to' here the same as 'refer to'? Again possibly taking 'link' in a physical rather than a referring sense.
[skw26]I feel uncomfortable with this phrasing. URI are the identifiers of the Web. A la Eng 90 it should be possible to refer to any (web) resource by URI. I don't understand how "agents provide". Somehow as association arises between an identifier and a thing. That may be through deployment or it may be denotational.
[skw27]Expunge 'mechanisms'. Suggest "Other systems of identifiers…"
[skw28]This makes sense only for Pat Hayes (C) sense of identifies ie. where the URI is used for resource retrieval/access.
Personally, I am also not sold on the context-freeness of URI usage.
[skw29]I'm wondering if we can speak of an association between an identifier and a resource and avoid the tar-pit of assignment and authority?
[skw30]This is flippant and dismissive - I'd delete it. I can speak of my paternal grandmother without naming her - but she is identified wrt to a named object (me).
[skw31]I find the notion of specificiations licensing… grates. I've lightly edited such that specifications specify.
[skw32]I find myself wanting to say simply "Agents SHOULD not associate arbitrarily different URI with the same resource". Resources/URI 'owners' form associations through deployment. However, other URI users may form different associations. There is a (C)/(D) difference here.
[skw33]Need to check with 2396bis too.
[skw34]This is basically that agents that exchange URI should use URI they are given as given, character for character. Assignment is irrelevant to this GPN.
[skw35](C) or (D) sense? Is it the case that a given URI both c-identifies and d-identifies the same one thing? The possibility of URI overloading acknowledged here suggests that this is already not the case.
[skw36]How?!!! Where is an agent to get such a definitive account? And how is it to get such a thing without using the URI in question?
[skw37]What properties? Substantiate the claim!
[skw38]How local? Loacl to what? Can there be global policies. Eg. a mailto: URI used as the object of foaf:mbox statement (inverseFunctional).
[skw39]Ownership confers rights and obligations. I think we should address URI and Resource ownership from that POV. We may then find that we have a problem with concepts of ownership.
[skw40]I think that 'create' here is a problem word. How do agents create URI. The use them. They associate them with things… but how do they 'create' them?
[skw41]I don't think any of the relevant specs. confer authority on anyone. There are RFCs about how register things with IANA, and some authority (somewhere) is conferred on IANA, presumably to make registrations. RFC2396 doesn't, the scheme specs don't… There is an element of social policy here that is orthogonal to the technology specifications.
[skw42]What is a unique relationship? 1-1, 1-N, N-1?
[skw43]What is a social entity?
[skw44]You appear to be using ownership and authority nearly synonymously. I think we need to say that authority may be vested in a specification, and organisational entity or an individual person or agent.
[skw45]I don't understand what this is trying to say.
[skw46]"New URI schemes SHOULD NOT be introduced when and existing scheme provides the desired properties…." Or stated more positively "Use extisting URI schemes whenever possible."
[skw47]Is this the right place for this comment. It seems more general to URI than to URI schemes.
[skw48]I know this is picky and I keep returning to it. The language in the spec says that "mailto URI are used to designated internet mailboxes." It is not a closed defn, though it may have meant to have been. However it is not restrictive - its says that they are used to designate internet mailboxes. It does not say that they are not/may not be used to designate other things.
[skw49](D) sense of identify.