The World Wide Web is an network-spanning information space of
resources interconnected by links. This information space is the
basis of, and is shared by, a number of information systems. Within
each of these systems, agents (e.g., browsers, servers, spiders,
and proxies) retrieve, create, display, analyze, and reason about
resources.
Web architecture encompasses the definition of the information
space in terms of identification and representation of its
contents, and of the protocols that support the interaction of
agents within an information system making use of the space. Web
architecture is influenced by social requirements and software
engineering principles, leading to design choices that constrain
the behavior of systems using 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. This document reflects the three
dimensions of Web architecture: identification, interaction, and
representation.
Editor's note: The TAG expects to
rewrite the abstract in light of other changes to the document.
The World Wide Web (WWW, or simply Web) is an
information space in which the things of interest, referred to
collectively as resources, are identified by
global identifiers called URIs.
A travel
scenario is used throughout this document to illustrate typical
behavior of Web
agents — software acting on this information space
on behalf of a person, entity, or process. Agents include servers,
proxies, browsers, spiders, multimedia players, and other user
agents (software acting on behalf of a person).
Story
While planning a trip to Mexico, Nadia reads "Oaxaca weather
information: 'http://weather.example.com/oaxaca
'" in a
glossy travel magazine. Nadia has enough experience with the Web to
recognize that "http://weather.example.com/oaxaca
" is
a URI. Given the context in which the URI appears, she expects that
it allows her to access weather information. When Nadia enters the
URI into her browser:
- The browser performs an information retrieval action in
accordance with its configured behavior for resources identified
via the "http" URI scheme.
- The authority responsible for "weather.example.com" responds to
the retrieval action, providing information in a response.
- The browser displays the retrieved information, which includes
links to other information via additional URI references. Nadia can
follow these links to initiate new retrieval request actions.
This scenario (elaborated on throughout the document)
illustrates the three architectural dimensions of the Web that are
discussed in this document:
- Identification. Each
resource is identified by
a Uniform Resource Identifier (URI). In this
travel scenario, the resource involves the weather in Oaxaca and
the URI is "
http://weather.example.com/oaxaca
".
- Interaction. Protocols
define the syntax and semantics of messages exchanged by agents
over a network about Web resources. Web agents communicate
information about the state of a resource through representations. In the travel
scenario, Nadia (by clicking on a link) tells her browser to request a
representation of the resource identified by the URI in the 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/xml+xhtml".
- Formats. Representations
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 is
XHTML, which includes links to several SVG weather map images.
While interpreting the XHTML representation data, which includes
references to weather maps identified by URIs; the browser
retrieves and displays those maps.
The following illustration shows the simplest relationship
between identifier, resource, and representation.
Editor's note: The TAG may include
additional illustrations in this document to help explain important
terms and their relationships.
This document attempts to describe the properties we desire of
the Web and the design choices that have been made to achieve
them.
This document promotes re-use of existing standards when
suitable, and gives guidance on how to innovate in a manner
consistent with the Web architecture.
This document is intended to inform discussions about issues of
Web architecture. The intended audience for this document
includes:
- Participants in W3C Activities; i.e., developers of Web
technologies and specifications in W3C
- Other groups and individuals developing technologies to be
integrated into the Web
- Implementers of W3C specifications
- Web content authors and publishers
Readers will benefit from familiarity with the Requests for Comments
(RFC) series from the IETF, some of which define pieces
of the architecture discussed in this document.
This document focuses on the 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 strives for brevity and precision while including
illustrative examples. TAG findings provide
more background, motivation, and examples. The findings do not
contain good practice notes, principles, etc. beyond those that
appear in the current document.
The architecture described in this document is primarily the
result of experience. Researchers in this area have proposed a
theoretical basis and formal model for Web architecture, notably
Roy Fielding's work on "Representational State Transfer" [REST]. Authors of protocol
specifications in particular should invest time in understanding
the REST model and consider the role to which of its principles
could guide their design: statelessness, clear assignment of roles
to parties, uniform address space, and a limited, uniform set of
verbs.
A number of general architecture principles apply to across all
three dimensions of Web architecture.
Identification, interaction, and representation are orthogonal
concepts: an identifier can be assigned without knowing what
representations are available, agents can interact with any
identifier, and representations can change without regard to the
identifiers or interactions that may dereference them.
Orthogonality is an important principle in Web architecture. It
facilitates a flexible design that can evolve over time. The fact,
for example, that the an image can be identified using a URI
without needing any information about the representation of that
image allowed PNG and SVG to evolve independent of the
specifications that define image elements.
Orthogonal abstractions deserve orthogonal specifications. When
it is necessary for a specification to define a feature that
simultaneously accesses information from otherwise orthogonal
abstractions, for example a feature that requires information from
both the header and the body of a message or a feature that needs
to infer information about the representations of a URI that are
available, the fact that it is "peeking" across architectural
boundaries should be clearly identified.
Good practice: Identify features that
cross abstraction levels
Format specification authors SHOULD clearly
identify the features of a specification that cross abstraction
levels.
Errors occur in networked information systems. The manner in
which they are dealt with depends on application context. User
agents act on behalf of the user and therefore are expected to help
the user understand the nature of errors, and possibly overcome
them. User agents that correct errors without the consent of the
user are not acting on the user's behalf.
Principle: Error
recovery
Silent recovery from error is harmful.
To promote interoperability, specifications should set
expectations about behavior in the face of known error conditions.
Experience has led to the following observation about
error-handling approaches.
- Protocol designers should provide enough information about the
error condition so that a person or agent can address the error
condition. For instance, an HTTP 404 message ("resource not found")
is useful because it allows agents to present information to users
that enables them to contact the author of the representation that
included the (broken) link. Similarly, experience with the cost of
building a user agent to handle the diverse forms of ill-formed
HTML content convinced the authors of the XML specification to
require that agents fail deterministically upon encountering
ill-formed content. Because users are unlikely to tolerate such
failures, this design choice has pressured all parties into
respecting XML's constraints, to the benefit of all.
- There are costs and benefits when an agent ignores unrecognized
content. The common practice by HTML user agents of ignoring
unknown elements contributed to the growth of the Web by allowing
the rapid deployment of new ideas. However, this behavior also
contributed to interoperability problems among early browsers. See
the section on extensibility
and versioning for related information.
- Error behavior that is appropriate for a person may not be
appropriate for a processor. 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.
Good practice: Specify
error handling
Specification authors SHOULD specify agent
behavior in the face of error conditions.
See the TAG finding "Client
handling of MIME headers" for more discussion about
error reporting. See also TAG issue errorHandling-20.
The Web follows the Internet tradition of having its important
interfaces defined not in terms of APIs or data structures or
object models, but in terms of syntax, by specifying the content
and sequence of the messages interchanged. It commonly occurs that
programmers working with the Web write code directly to generate
and parse these messages. It is a bit less usual, though not
altogether uncommon, for end users to have direct exposure to these
messages. This leads to the well-known "view source" effect,
whereby users gain expertise in the workings of the systems by
direct exposure to the underlying protocols.
Widespread APIs such as the Simple API for XML (SAX) greatly
facilitate the development of Web software, and XPath and XQuery
show the importance of abstract data models. And quality assurance
can have as much impact on interoperability as any of these factors
or others. But the technology that is shared between agents in the
Web lasts longer than the agents themselves. Web Architecture has
thus focussed on concrete syntax and protocols shared between
agents.
Parties who wish to communicate about something agree upon a
shared set of identifiers and on their meanings. This shared
vocabulary has a tangible value: it reduces the cost of
communication. The ability to use common identifiers across
communities motivates global identifiers in Web architecture. Thus,
Uniform Resource
Identifiers [URI], which
are global identifiers in the context of the Web, are central to
Web architecture.
Constraint: Identify with
URIs
The identification mechanism for the Web is
the URI.
A URI must be assigned to a resource in order for the resource
to be linked-to within the
information space. It follows that a resource should be assigned a
URI if a third party might reasonably want to link to it, make or
refute assertions about it, retrieve or cache a representation of
it, include all or part of it by reference into another
representation, annotate it, or perform other operations on it.
Constraint: URI
uniqueness
Web architecture does not constrain a Web
resource to be identified by a single URI.
Resources exist before URIs; a resource may be identified by
zero URIs. However, there are many benefits to assigning a URI to a
resource, including linking, bookmarking, caching, and indexing by
search engines. Designers should expect that it will prove useful
to be able to share a URI across applications, even if that utility
is not initially evident. Remember that the scope of a URI is
global: the resource identified by a URI does not depend on the
context in which the URI appears. Of course, what an agent does
with a URI may vary. The TAG finding "URIs,
Addressability, and the use of HTTP GET and POST"
discusses additional benefits and considerations.
Principle: Assign URIs
A resource owner SHOULD assign a URI to each
resource that is intended to be identified, shared, or described by
reference.
This principle dates back at least as far as Douglas Engelbart's
seminal work on open hypertext systems; see section Every
Object Addressable in [Eng90].
As stated above, Web architecture allows resource owners to
assign more than one URI to a resource. Thus, URIs that are not
identical (character for character) necessarily refer to different
resources. The most straightforward way of establishing that two
parties are referring to the same Web resource is to compare, as
character strings, the URIs they are using. URI equivalence is
discussed in section 6 of [URI]
Good practice: Thoughtful URI
creation
Resource owners should not create arbitrarily
different URIs for the same resource.
URI producers should be conservative about the number of
different URIs they produce for the same resource. For example, the
parties responsible for weather.example.com should not use both
"http://weather.example.com/Oaxaca
" and
"http://weather.example.com/oaxaca
" to refer to the
same resource; agents will not detect the equivalence relationship
by following specifications. On the other hand, there may be good
reasons for creating similar-looking URIs. For instance, one might
reasonably create URIs that begin with
"http://www.example.com/tempo
" and
"http://www.example.com/tiempo
" to provide access to
resources by users who speak Italian and Spanish.
Likewise, URI consumers should ensure URI consistency. For
instance, when transcribing a URI, agents should not gratuitously
escape characters. The term "character" refers to URI characters as
defined section 2 of [URI].
Good practice: Use URIs
consistently
If a URI has been assigned to a resource,
agents SHOULD refer to the resource using the same URI, character
for character.
Applications may apply rules beyond basic string comparison
(e.g., for "http" URIs, the authority component is
case-insensitive) that are licensed by specifications to reduce the
risk of false negatives and positives. Web agents that reach
conclusions based on comparisons that are not licensed by relevant
specifications take responsibility for any problems that result.
Agents should not assume, for example, that
"http://weather.example.com/Oaxaca
" and
"http://weather.example.com/oaxaca
" identify the same
resource, since none of the specifications involved states that the
path part of an "http" URI is case-insensitive.
See section 6 [URI] for more
information about comparing URIs and reducing the risk of false
negatives and positives. See the section on future directions for
solutions other than string comparison that may allow different
parties to determine that
two URIs identify the same resource.
Just as a shared vocabulary has tangible value, the ambiguous
use of terms imposes a cost in communication. URI
ambiguity refers to the use of the same URI to refer to
more than one distinct resource. Consider the following scenario:
One division of a company maintains data about Web pages, including
who created them and when. This division naturally uses the URI of
the page to identify it. Another division of the company maintains
data about corporations, including who created them and when. They
use the URI of the corporation's home page to identify it.
If the two divisions decide to merge their data, they will have
to exercise care or the fact that they are using the same URIs to
identify two different resources will cause problems.
Ambiguity is an error and should not be confused with indirect
identification. Indirect identification occurs when a resource is
identified through another resource to which it has a known
relationship. For example, people can be identified by their email
addresses or organizations by their web pages. When conference
organizers ask meeting participants to register by giving their
email addresses, both parties know that they are using the mailbox
identifier to indirectly identify the person. The URI
"mailto:joe@example.com
" still identifies the mailbox,
not the person.
URI ambiguity should not be confused with ambiguity in natural
languages. The natural language statement
"'http://www.example.com/moby' identifies 'Moby Dick'" is ambiguous
because one could understand the statement to refer to very
distinct resources: a particular printing of this work, or the work
itself in an abstract sense, or the fictional white whale, or a
particular copy of the book on the shelves of a library (via the
Web interface of the library's online catalog), or the record in
the library's electronic catalog which contains the metadata about
the work, or the Gutenberg project's online version.
URI ambiguity only arises if different parties believe that
"http://www.example.com/moby" identifies different things.
Good practice: URI
ambiguity
Avoid URI ambiguity.
In the URI "http://weather.example.com/
", the
"http" that appears before the colon (":") is a URI scheme name.
Each URI scheme has a normative specification that explains how
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. Furthermore, the URI scheme
specification may specify whether and how an agent can dereference the URI.
Examples of URIs from various schemes include:
- mailto:joe@example.org
- ftp://example.org/aDirectory/aFile
- news:comp.infosystems.www
- tel:+1-816-555-1212
- ldap://ldap.example.org/c=GB?objectClass?one
- urn:oasis:SAML:1.0
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].
Since many aspects of URI processing are scheme-dependent, and
since a huge amount of deployed software already processes URIs of
well-known schemes, the cost of introducing a new URI scheme is
high.
Good practice: New URI
schemes
Authors of specifications SHOULD NOT introduce
a new URI scheme when an existing scheme provides the desired
properties of identifiers and their relation to resources.
Consider our travel
scenario: should the authority providing information about the
weather in Oaxaca register a new URI scheme "weather" for the
identification of resources related to the weather? They might then
publish URIs such as
"weather://travel.example.com/oaxaca
". While the Web
architecture allows the definition of new schemes, there is a cost
to registration and especially deployment of new schemes. When an
agent dereferences such a URI, if what really happens is that HTTP
GET is invoked to retrieve an HTML representation of the resource,
then an "http" URI would have sufficed. If a URI scheme exists that
meets the needs of an application, designers should use it rather
than invent one.
If the motivation behind registering a new scheme is to allow an
agent to launch a particular application when retrieving a
representation, such dispatching can be accomplished at lower
expense by registering a new Internet Media Type instead. Deployed
software is more likely to handle the introduction of a new media
type than the introduction of a new URI scheme.
Note: The TAG should provide more justification
for the preceding sentence. Some suggestions have been that this is
true currently but is not constrained by the arch to be so. Others
have commented that it's better to get a representation and deal
with it locally rather than not even be able to GET a
representation.
The use of unregistered URI schemes is discouraged for a number
of reasons:
- There is no generally accepted way to locate the scheme
specification.
- Someone else may be using the scheme for other purposes.
- One should not expect that general-purpose software will do
anything useful with URIs of this scheme; the network effect is
lost.
Note: Some URI scheme specifications use the
term "designate." This document uses "identify" rather than
"designate" in some of the descriptions above.
TAG issue siteData-36
is about expropriation of naming authority.
Editor's note: In a future version
of this document, the TAG may summarize some URI schemes and what
the scheme specification licenses agents to infer by recognizing
the scheme.
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 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 server is free to return a representation in the PNG
or any other format for that URI.
Resource state may evolve over time. Requiring resource owners
to change URIs to reflect resource state would lead to a
significant number of broken links. For robustness, Web
architecture promotes independence between an identifier and the
identified resource.
Good practice: URI
Opacity
Web agents making use of URIs MUST NOT attempt
to infer properties of the referenced resource except as licensed
by relevant specifications.
The example URI used in the travel scenario
("http://weather.example.com/oaxaca
") suggests that
the identified resource has something to do with the weather in
Oaxaca. A site reporting the weather in Oaxaca could just as easily
be identified by the URI "http://vjc.example.com/315
".
And the URI "http://weather.example.com/vancouver
"
might identify the resource "my photo album."
On the other hand, the URI "mailto:joe@example.com
"
indicates that the URI refers to a mailbox. The mailto URI scheme
specification authorizes Web agents to infer that URIs of this form
identify Internet mailboxes.
In some cases, relevant technical specifications license URI
assignment authorities to publish assignment policies. For more
information about URI opacity, see the TAG finding "The use of
Metadata in URIs".
Story
When navigating within the XHTML data that Nadia receives as a
representation of the resource identified by
"http://weather.example.com/oaxaca
", Nadia finds that
the URI "http://weather.example.com/oaxaca#tom
" refers
to information about tomorrow's weather in Oaxaca. This URI
includes the fragment identifier "tom" (the string after the
"#").
The fragment
identifier of a URI allows indirect identification of a
secondary resource by
reference to a primary resource and additional information. More
precisely:
- If URI "U" identifies primary resource "R", and
- a representation of "R" is in the data format "F", and
- the format specification for "F" specifies that fragment
identifiers in instances of "F" identify secondary resources,
then
- a URI for the secondary resource identified within an instance
of "F" by fragment identifier "fragid" is "U#fragid".
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. The interpretation of fragment
identifiers is discussed in the section on media types and fragment identifier
semantics. Note that one can use a URI with a fragment
identifier even if one does not have a representation handy for
interpreting the fragment identifier (e.g., one can compare two
such URIs).
Refer the TAG finding "Abstract
Component References" for information about indirect
identification of abstract components such as those identified in
description languages such as WSDL and RDF.
There remain open questions regarding identifiers on the Web.
The following sections identify a few areas of future work in the
Web community. The TAG makes no commitment at this time to pursuing
these issues.
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.
Emerging Semantic Web technologies, including "DAML+OIL" [DAMLOIL] and "Web Ontology
Language (OWL)" [OWL10], define
RDF properties such as equivalentTo
and
FunctionalProperty
to state assert that two URIs
identify the same resource.
The Dynamic Delegation Discovery System
(DDDS) ([RFC3401] and related RFCs) is used to implement
lazy binding of strings to data, in order to support dynamically
configured delegation systems. This system is designed to allow
resolution of any type of URI, in particular URNs.
One area of work involves the creation of globally unique
identifiers in a file-sharing system without centralized or
hierarchical administration.
URIs are designed to work equally well on a Web of one computer
or a Web of 1 billion computers. The exchange of information in a
world of 1 billion computers is another story. A successful
interaction architecture must account for the physical distance
messages travel, network outages, representing information to allow
shared understanding, multiple trust boundaries, and many other
distributed communication issues. In this section we discuss the
basis of the Web's interaction model.
Communication between Web agents over a network about resources
involves URIs, messages, and data.
Story
Nadia follows a link labeled "satellite image" expecting to
retrieve a satellite photo of the Oaxaca region. The link to the
satellite image is an XHTML link encoded as <a
href="http://example.com/satimage/oaxaca">satellite
image</a>
. Nadia's browser analyzes the URI and
determines that its scheme
is "http". The browser configuration determines how it locates the
identified information, which might be via a cache of prior
retrieval actions, by contacting an intermediary (e.g., a proxy
server), or by direct access to the server identified by the URI.
In this example, the browser opens a network connection to port 80
on the server at "example.com" and sends a "GET" message as
specified by the HTTP protocol, requesting a representation of the
resource identified by "/satimage/oaxaca".
The server sends a response message to the browser, once again
according to the HTTP protocol. The message consists of several
headers and a JPEG image. The browser reads the headers, learns
from the 'Content-Type' field that the Internet Media Type of the
representation is image/jpeg
, reads the sequence of
octets that comprises the representation data, and renders the
image.
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.
Editor's note: The TAG has not yet
reached agreement about whether to distinguish "information
resources" from other types of resources. An information resource
is one that conveys information (via representations). See TAG
issue httpRange-14.
Related to the concept of "information resource" is the expression
"on the Web". Roy Fielding suggested this definition of "on the
Web": "A resource is considered to be "on the Web" if it can be
independently referred to by at least one URI, even if access to
that resource is restricted." Others have expressed that actual
access should be a requirement as well.
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
resource state (e.g., using HTTP GET or HEAD), modifying the state
of the resource (e.g., using HTTP POST or PUT), and deleting the
resource (e.g., using HTTP DELETE).
There may be more than one way to access a resource for a given
URI; context may determine 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 (e.g., the URN scheme [RFC 2141]) do not set expectations
about available access mechanisms. 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 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, and the resolution of some URIs may require
the use of more than one protocol (e.g., both DNS and HTTP are
typically used to access an "http" URI's origin server when a
representation isn't found in a local cache).
Dereferencing a URI generally involves a succession of steps as
defined in multiple independent specifications and implemented by
the agent. The following example illustrates the series of
specifications that are involved when an agent dereferences the URI
"http://weather.example.com/oaxaca
" that is part of a
link in an SVG document.
- Since the URI is part of a link in an SVG document, the first
relevant specification is the SVG 1.1 Recommendation [SVG11]. This specification imports
the link semantics defined in XLink 1.0 [XLink10]. Section 17.1 of the SVG specification
suggests that interaction with an
a
link involves
retrieving a representation of a resource, identified by the XLink
href
attribute: "By activating these links (by
clicking with the mouse, through keyboard input, and voice
commands), users may visit these resources."
- The XLink 1.0 [XLink10]
specification, which defines the attribute
xlink:href
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."
- 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".
- [IANASchemes] states
that the "http" scheme is defined by the HTTP/1.1 specification
(RFC 2616 [RFC2616], section
3.2.2).
- Section 9.3 of [RFC2616]
states how the server constructs a GET response (section 6 of [RFC2616]), including the
'Content-Type' field. In this SVG context, the user agent employs
the GET method to retrieve the representation.
- 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.
- The user 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].
Editor's note: Chris Lilley is
expected to provide a revised version of the above sequence.
A message
is an event that is represented in a non-exclusive set of messaging
protocols (e.g., HTTP, FTP, NNTP, SMTP, etc.). Messages may carry
data, metadata about the data, and message metadata: metadata
about the message (e.g., the HTTP Transfer-encoding header). A
message may even include metadata about the message metadata (e.g.,
for message-integrity checks).
Two important classes of message are those that request a
representation of a resource, and those that return the result of
such a request. Such a response message (e.g., a response to an
HTTP GET) carries a representation of the state
of the resource. A representation is an octet sequence that
consists logically of two parts:
- Electronic data about resource state, expressed in one or more
formats used separately or in
combination, and
- Representation
metadata, especially the Internet Media Type which governs
the interpretation of the representation data.
Some protocols (such as HTTP) may also allow agents to exchange
resource
metadata. For example when using HTTP, some resource
metadata is specified by headers such as 'Alternates' and
'Vary'.
Agents use representations to modify as well as retrieve
resource state. Note that even though the response to an HTTP POST
request may contain the above types of data, the response to an
HTTP POST request is not a representation of the state of the
resource identified in the POST request.
The Internet Media Type [RFC2046]) governs the authoritative
interpretation of representation data, and the IANA registry [MEDIATYPEREG] determines the
format
specifications that provide the authoritative interpretation
for a given Internet Media Type. If the user agent implements those
specifications, it interprets the data accordingly; error handling is discussed below. In
this document, the phrase "media type M" is shorthand for "the data
format defined by the specification(s) paired with Internet Media
Type M in the IANA registry."
The URI specification [URI]
states that given a URI with a fragment identifier "U#F":
- The authoritative interpretation of "F" depends on the format specification
of representation data that is part of a representation of the
resource identified by "U".
The interpretation of "F" does not depend on the representation
where "U#F" appears but on the representation retrieved by
dereferencing "U".
Interpretation of the fragment identifier during a retrieval
action is performed solely by the agent; the fragment identifier is
not passed to other systems during the process of retrieval. This
means that some intermediaries in the Web architecture (e.g.,
proxies) have no interaction with fragment identifiers and that
redirection (in HTTP [RFC2616],
for example) does not account for them.
For a given resource, an agent may have the choice between
representation data in more than one data format (e.g., through
HTTP content negotiation). Since different data formats may define
different fragment identifier semantics, it is important to note
that by design the secondary resource identified by a URI with a
fragment identifier is expected to be the same independent of
representations. Thus, if a fragment has defined semantics in any
one representation, the fragment is identified for all of them,
even though a particular format cannot represent it.
Suppose, for example, that the party responsible for
"http://weather.example.com/oaxaca/map#zicatela
"
provides representations of the resource identified by
http://weather.example.com/oaxaca/map
using three
image formats: SVG, PNG, and JPEG/JFIF. The SVG specification
defines semantics for fragment identifiers while the other
specifications do not. It is not considered an error that only of
the data formats specifies semantics for the fragment identifier.
Because the Web is a distributed system in which formats and agents
are deployed in a non-uniform manner, the architecture allows this
sort of discrepancy. Authors may take advantage of more powerful
data formats, while still ensuring reasonable
backward-compatibility for users whose agents do not yet implement
them.
On the other hand, it is considered an error if the semantics of
the fragment identifiers used in two representations of a secondary
resource are inconsistent.
Good practice: Fragment
identifier consistency:
A resource owner that creates a URI with a
fragment identifier and that uses content negotiation to serve
multiple representations of the identified resource SHOULD NOT
serve representations with inconsistent fragment identifier
semantics.
See related TAG issues httpRange-14
and RDFinXHTML-35.
Successful communication between two parties using a piece of
information relies on shared understanding of the meaning of the
information. Arbitrary numbers of independent parties can identify
and communicate about a Web resource. To give these parties the
confidence that they are all talking about the same thing when they
refer to "the resource identified by the following URI ..." the
design choice for the Web is, in general, that the owner of a
resource assigns the authoritative interpretation of
representations of the resource. See the TAG finding "Client
handling of MIME headers" for related discussion. See
also TAG issue rdfURIMeaning-39.
In our travel scenario, the
authority responsible for "weather.example.com" has license to
create representations of this resource and assign their
authoritative interpretation. Which representation(s) Nadia
receives depends on a number of factors, including:
- Whether the authority responsible for "weather.example.com"
responds to requests at all;
- Whether the authority responsible for "weather.example.com"
makes available one or more representations for the resource
identified by
"
http://weather.example.com/oaxaca
";
- Whether Nadia has access privileges to such a
representation;
- If the authority responsible for "weather.example.com" has
provided more than one representation (in different formats such as
HTML, PNG, or RDF, in different languages such as English and
Spanish, etc.), the resulting representation may depend on
negotiation between the user agent and server that occurs as part
of the HTTP transaction.
- When Nadia made the request. Since the weather in Oaxaca
changes, Nadia should expect that representations will change over
time.
Inconsistencies between the format of representation data and
assigned representation metadata do occur. Examples that have been
observed in practice include:
- The actual character encoding of a representation is
inconsistent with the charset parameter in the representation
metadata.
- The namespace of the root element of the representation data is
inconsistent with the value of the 'Content-Type' field in HTTP
headers.
User agents should detect such inconsistencies but should not
resolve them without involving the user.
Principle: Authoritative server
metadata
User agents MUST NOT silently ignore
authoritative server metadata.
Thus, for example, if the parties responsible for
"weather.example.com" mistakenly label the satellite photo of
Oaxaca as "image/gif" instead of "image/jpeg", and if Nadia's
browser detects a problem, Nadia's browser must not silently ignore
the problem and render the JPEG image. Nadia's browser can notify
Nadia of the problem, notify Nadia and take corrective action, etc.
Of course, user agent designers should not ignore usability issues
when handling this type of error; notification may be discreet, and
handling may be tuned to meet the user's preferences.
See the TAG finding "Client
handling of MIME headers" for more in-depth discussion
and examples.
Furthermore, server managers can help reduce the risk of error
through careful assignment of representation metadata.
Principle: Don't guess
metadata
Server managers MUST ensure that
representation metadata is appropriate for each representation.
Editor's note: Add an example of
this principle.
Story
Nadia decides to book a vacation to Oaxaca at
"booking.example.com." She enters data into a series of HTML forms
and is ultimately asked for credit card information to purchase the
airline tickets. She provides this information in another HTML
form. When she presses the "Purchase" button, her browser opens
another network connection to the server at "booking.example.com"
and sends a message conforming to the rules for an HTTP POST
request.
As described by the HTML specification, the message data
consists of a set of name/value pairs corresponding to the HTML
form fields. Note that this is not a safe interaction; Nadia wishes to
change the state of the system by exchanging money for airline
tickets.
The server reads the POST request, and after performing the
booking transaction returns a message to Nadia's browser that
contains a representation of the results of Nadia's request. The
representation data is in HTML so that it can be saved or printed
out for Nadia's records. Note that neither the data transmitted
with the POST nor the data received in the response necessarily
correspond to any resource named by a URI.
Nadia's retrieval of weather information qualifies as a "safe"
interaction; a safe interaction is one
where the agent does not commit to anything beyond the interaction
and is not responsible for any consequences other than the
interaction itself (e.g., a read-only query or lookup). 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.
Safe interactions are important because these are interactions
where users can browse with confidence and where agents (e.g.,
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.
Principle: Safe
retrieval
Agents do not incur obligations by retrieving
a representation.
For instance, it is incorrect to publish a link (e.g.,
"http://example.com/oaxaca/newsLetter
") 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".
Story
Since Nadia finds the Oaxaca weather site useful, she emails a
review to her friend Dirk recommending that he check out
'http://weather.example.com/oaxaca
'. Dirk clicks on
the link in the email he receives and is surprised to see his
browser display a page about auto insurance. Dirk confirms the URI
with Nadia, and they both conclude that the resource is unreliable.
Although the managers of Oaxaca have chosen the Web as a
communication medium (since, for example, it costs less to update a
Web site than to reprint and distribute weather information on
paper), they have lost two customers due to ineffective resource
management.
The usefulness of a resource depends on good management by its
owner. As is the case with many human interactions, confident
interactions with a resource depend on stability and
predictability. The value of a URI increases with the
predictability of interactions using that URI. Thoughtful URI creation is one aspect
of proper resource management.
Good practice: Consistent
representations
Publishers of a URI SHOULD provide (or not)
representations of the identified resource consistently and
predictably.
This section discusses important aspects of representation
management.
The authority responsible for a resource may supply zero or more
representations of a resource. The authority is also responsible
for accepting or rejecting requests to modify a resource, e.g., by
configuring a server to accept or reject HTTP PUT data based on
Internet Media Type, validity constraints, or other
constraints.
Good practice: Available
representations
Publishers of a URI SHOULD provide
representations of the identified resource.
In terms of user frustration, there is little difference between
the inability to retrieve a representation for an important
resource due to a network outage and the inability because none has
been provided.
There are strong social expectations that once a URI identifies
a particular resource, it should continue indefinitely to refer to
that resource; this is called URI persistence. URI
persistence is a matter of policy and commitment on the part of
authorities servicing URIs. The choice of a particular URI scheme
provides no guarantee that those URIs will be persistent or that
they will not be persistent.
Since representations are used to communicate resource state,
persistence is directly affected by how well representations are
served. Service breakdowns include:
- Inconsistent representations served. Note the difference
between a resource owner changing representations predictably in
light of the nature of the resource (e.g., the weather in Oaxaca
changes) and the owner changing representations arbitrarily.
- Improper use of content negotiation, such as serving two images
as equivalent through HTTP content negotiation, where one image
represents a square and the other a circle.
HTTP [RFC2616] has been
designed to help service URIs. For example, HTTP redirection (using
the 3xx response codes) permits servers to tell a user agent that
further action needs to be taken by the user agent in order to
fulfill the request (e.g., the resource has been assigned a new
URI). In addition, content negotiation also promotes consistency,
as a site manager is not required to define new URIs when adding
support for a new format specification. Protocols that do not
support content negotiation (e.g., FTP) require a new identifier
when a new format is introduced.
For more discussion about URI persistence, see [Cool].
It is reasonable to limit access to the resource (e.g., for
security reasons), but it is unreasonable to prohibit others from
merely identifying the resource.
As an analogy: 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.
Story
Nadia and Dirk both subscribe to the "weather.example.com"
newsletter. Nadia wishes to point out an article of particular
interest to Dirk, using a URI. The authority responsible for
"weather.example.com" can offer newsletter subscribers such as
Nadia and Dirk the benefits of URIs (e.g., book marking and
linking) and still limit access to the newsletter to authorized
parties.
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, and the Semantic Web.
Data formats (e.g., XHTML, CSS, PNG, XLink, RDF/XML, and SMIL
animation) are used to build representations. Each data format is
defined by a format specification. 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.
Some characteristics of a data format make it easier to
integrate into the Web architecture. We examine some of those
characteristics below. This document does not address generally
beneficial characteristics of a specification such as readability,
simplicity, attention to programmer goals, attention to user needs,
accessibility, internationalization, etc. The section on architectural specifications
includes references to additional format specification
guidelines.
Note: This document does not distinguish in any
formal way the terms "format," "language," and "vocabulary."
Context has determined which term is used.
For a data format to be usefully interoperable between two
parties, the parties must have a shared understanding of its syntax
and semantics. This is not to imply that a sender of data
can count on constraining its treatment by a receiver; simply that
making good use of a data format requires knowledge of its
designers' intentions.
Good practice: Format
specification availability
To promote the interoperability of a Web data
format, the format authors SHOULD provide a stable, normative
specification for it that is a widely available Web resource.
Good practice: Media type
registration
Format specification authors SHOULD register an
Internet Media Type for each format specification they wish to
promote (see the [MEDIATYPEREG] registry).
See TAG finding "Internet Media
Type registration, consistency of use" for more
information.
Good practice: Specified fragment
identifier semantics
Format specification authors SHOULD define the
syntax and semantics of fragment identifiers for the format.
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 very expensive. Thus, before
inventing a new data format, designers should carefully consider
re-using one that is already available.
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.
In modern textual data formats, the characters are usually taken
from the Unicode repertoire [UNICODE].
Binary data formats are those in which portions of the data are
encoded for direct use by computer processors, for example
thirty-two bit little-endian two's-complement and sixty-four bit
IEEE double-precision floating-point. The portions of data so
represented include numeric values, pointers, and compressed data
of all sorts.
In principle, all data can be represented using textual
formats.
The trade-offs between binary and textual data formats are
complex and application-dependent. Binary formats can be
substantially more compact, particularly for complex pointer-rich
data structures. Also, they can be consumed more rapidly by agents
in those cases where they can be loaded into memory and used with
little or no conversion.
Textual formats are usually more portable and interoperable,
since there are fewer choices for representation of the basic units
(characters), and those choices are well-understood and widely
implemented.
Textual formats also have the considerable advantage that they
can be directly read and understood by human beings. This can
simplify the tasks of creating and maintaining processing software,
and allow the direct intervention of humans in the processing chain
without recourse to tools more complex than the ubiquitous text
editor. Finally, it simplifies the necessary human task of learning
about new data formats (the "View Source" effect).
It is important to emphasize that intuition as to such matters
as data size and processing speed are not a reliable guide in data
format design; quantitative studies are essential to a correct
understanding of the trade-offs.
Good practice: Binary or text
Format specification authors SHOULD make a
considered choice between binary and textual.
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 such formats are not primarily comprised 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.
TAG issue binaryXML-30:
Effect of Mobile on architecture - size, complexity, memory
constraints. Binary Infosets, storage efficiency.
The information that people represent in the Web and the
technologies they use to represent that information change over
time. Versioning is the process of managing that change.
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
(thus keeping down the cost of change). Some examples of successful
technologies designed to allow change while minimizing disruption
include: URI schemes, Internet Media Types, XML Namespaces,
Cascading Style Sheets rules for handling unknown style properties
and property values, SOAP extensibility model, and user agent
plug-ins.
Good practice: Allow for
extensions
Format designers SHOULD provide mechanisms that
allow any party to create extensions that do not interfere with
conformance to the original specification.
Application needs determine the most appropriate extension
strategy. For example, applications designed to operate in closed
environments may be able to employ versioning strategies that would
be impractical on the distributed system of the Web as a whole. See
the work on RDF ontologies (e.g., [OWL10]) for one example of a well-defined
solution for mixing arbitrary ontologies.
There is typically a (long) transition period during which
multiple versions of a format, protocol, or agent are
simultaneously in use.
Good practice: Provide version
information
Format designers SHOULD provide for version
information in language instances.
See the section on XML
namespaces and versioning for more information about using a
namespace name as the basis of version information.
Designers can make the transition process smoother by making
careful choices about versioning and extensibility, in particular
with regard to compatibility:
- Design for forward-compatible processing. XSLT 1.0, for
example, was designed so that XSLT 1.0 processors would operate
predictably when processing stylesheets authored in later versions
of the specification.
- Make backward-compatible changes so that newer processors can
also handle older data.
Agent behavior in the face of unrecognized content will vary
according to application needs, security issues, etc. Application
needs will determine the appropriate behavior.
Good practice: Unknown
extensions
Format designers SHOULD specify agent behavior
in the face of unrecognized extensions.
Two strategies have emerged as being particularly useful:
- "Must ignore": The agent ignores any content it does not
recognize.
- "Must understand": The agent stops processing as soon as it
encounters content it does not recognize.
Additional strategies include prompt the user for more input,
automatically retrieve data from available links, and fall back to
default behavior. More complex strategies are also possible,
including mixing strategies. For instance, a format can include
mechanisms for overriding standard behavior. Thus, a format can
specify "must ignore" semantics but also allow people to create
extensions that override that semantics in light of application
needs (e.g., with "must understand" semantics for a particular
extension).
For more information on about versioning strategies and agent
behavior in the face of unrecognized extensions, see the TAG
finding "Versioning
XML Languages". See also "Web Architecture: Extensible
Languages" [EXTLANG].
The Web is a heterogeneous environment where a wide variety of
user 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 cell phones, and
users with disabilities who may require speech synthesizers or
other specialized hardware or software. Furthermore, authors cannot
predict how every user agent will display or process their content.
Experience shows that the allowing authors to separate content
logic from presentation and interaction concerns helps them reach
the widest possible audience.
Good practice: Content, Presentation, Interaction
Separation
Format specification authors SHOULD design
formats that allow authors to separate content logic from
presentation and interaction concerns.
Of course, it is not always desirable to reach the "widest
possible audience". Application context may require a very specific
display (e.g., for some legally-binding transaction). Also, digital
signature technology, access
control, and other technologies are appropriate for controlling
access to content.
See the general principle on orthogonal specifications and the TAG
issues formattingProperties-19
and contentPresentation-26.
A defining characteristic of the Web is that it allows embedded
references to other Web resources via URIs. The simplicity of
<a href="#foo">
as a link to foo
and <a name="foo">
as the anchor
foo
are partly (perhaps largely) responsible for the
birth of the hypertext Web as we know it today.
When a representation of one resource
refers to another resource with a URI, this constitutes a link between the two
resources. The networked information space is built of linked
resources, and the large-scale effect is a shared information
space. The value of the Web grows exponentially as a function of
the number of linked resources (the "network effect").
A link is built from two pieces:
- a base URI, which
is associated with the representation in which the link appears,
and
- a URI reference
(defined in section 4.2 of [URI]).
Strings such as "#anchor" and "../" are familiar examples of URI
references.
Web agents resolve a URI reference before using the resulting
URI to interact with another agent. This split design facilitates
content management. by allowing authors to design a representation
locally, i.e., without worrying about what global identifier may
later be used to refer to the associated resource.
Section 5 of [URI] explains how
to create a URI by composing a base URI and a URI reference; this
is called resolving a URI reference. Section 5.1 explains different
mechanisms specifying a base URI for a representation and
establishes a precedence among the various mechanisms. Two examples
of such mechanisms are the "base" element in HTML and XML, and the
HTTP 'Content-Location' header.
Good practice: Link
mechanisms
Format specification authors SHOULD provide
mechanisms for identifying links to other resources and to portions
of representation data (via fragment identifiers).
Good practice: Web linking
Format specification authors SHOULD provide
mechanisms that allow Web-wide linking, not just internal document
linking.
What agents do with a link is not constrained by Web
architecture. Agent behavior depends on application context, which
may include additional metadata about the relationship embodied by
the link. For instance, agents may consider a link may to be active
or passive. Hypertext browsers usually consider anchors and in-line
image references to be active links (also called hyperlinks).
Behavior may vary for these links however: a user agent may
retrieve an image automatically but require user interaction in
order to follow a link specified with an element such as "a" in
HTML. On the other hand, a reasoning system might focus activity on
assertions, a messaging agent might traverse service descriptions,
or a subscriber might describe "callback" control-points.
Good practice: Generic URIs
Format specification authors SHOULD allow
authors to use URIs without constraining them to a limited set of
URI schemes.
Users of the hypertext Web expect to be able to navigate links
among representations. Data formats that do not allow authors to
create hyperlinks lead to the creation of "terminal nodes" on the
Web.
Good practice: Use of
Hyperlinks
Format specification authors SHOULD incorporate
hypertext links into a format if hypertext is the expected user
interface paradigm.
Per the above good practice note, hypertext links should be
based on URIs. See also the section on links in XML.
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 very thorough discussion of the considerations
that govern whether or not XML ought to be used, as well as
specific guidelines on how it ought to be used. While it is
directed at Internet applications with specific reference to
protocols, the discussion is generally applicable to Web scenarios
as well.
The discussion here should be seen as ancillary to the content
of [IETFXML]. Refer also to
"XML Accessibility Guidelines" [XAG] for help designing XML formats that lower
barriers to Web accessibility for people with disabilities.
XML defines textual data formats that are naturally suited to
describing data objects which are hierarchical and processed in an
in-order sequence. It is widely, but not universally applicable for
format specifications; 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:
- Requirement for a hierarchical structure.
- The data's usefulness should outlive the tools currently used
to process it.
- Ability to support internationalization in a self-describing
way that makes confusion over coding options unlikely.
- Early detection of encoding errors with no requirement to "work
around" such errors.
- A high proportion of human-readable textual content.
- 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 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.
For formats based on XML, format designers should consider using
XLink and the XPointer framework. To define fragment identifier
syntax, use at least the XPointer Framework and XPointer element()
Schemes.
TAG issue: What is the scope of using XLink? xlinkScope-23.
Good practice: QName
Mapping
Format specification authors who use QNames
MUST provide a mapping to URIs.
Good practice: QNames
Indistinguishable from URIs
Format specification authors MUST NOT define an
attribute whose value may be either a URI or QName since the two
types cannot be distinguished by syntax.
Editor's note: The two previous
points need more introduction.
See the TAG finding "Using QNames as
Identifiers in Content" for more information. See also
TAG issues rdfmsQnameUriMapping-6
and qnameAsId-18.
Story
The authority responsible for "weather.example.com" realizes
that it can provide more interesting representations by creating
instances that consist of elements defined in different XML-based formats, such as
XHTML, SVG, and MathML.
How do the application designers ensure that there are no naming
conflicts when they combine elements from different formats (e.g.,
suppose that the "p" element is defined in two or more XML
formats)? "Namespaces in XML" [XMLNS] provides a mechanism for establishing a
globally unique name that can be understood in any context.
The "expanded name" of an XML element or attribute name is the
combination of its namespace URI and its local name. This is
represented lexically in documents by associating namespace names
with (optional) prefixes and combining prefixes and local names
with a colon as described in "Namespaces in XML."
Format specification designers that declare namespaces thus
provide a global context for instances of the data format.
Establishing this global context allows those instances (and
portions thereof) to be re-used and combined in novel ways not yet
imagined. Failure to provide a namespace makes such re-use more
difficult, perhaps impractical in some cases.
Good practice: Use
Namespaces
Format specification authors that create new
XML vocabularies SHOULD place all element names and global
attribute names in a namespace.
Attributes are always scoped by the element on which they
appear. In that respect they are a somewhat special case. An
attribute that is "global," that is, one that might meaningfully
appear on different elements, including elements in other
namespaces, should be explicitly placed in a namespace. Local
attributes, ones associated with only a particular element, need
not be included in a namespace since their meaning will always be
clear from the context provided by that element.
The type
attribute from W3C XML Schema is an
example of a global attribute. It can be used by authors of any
vocabulary to make an assertion about the type of the element on
which it appears. The type
attribute occurs in the W3C
XML Schema namespace and must always be fully qualified. The
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 very 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 semantically significant in ways that
are not anticipated by [XMLNS].
Story
Nadia and Dirk are designing an XML format to encode data about
the film industry. They provide for extensibility by using XML
namespaces and creating a schema that allows the inclusion, in
certain places, of elements from any namespace. When they revise
their format, Nadia proposes a new optional "lang" attribute on the
"film" element. Dirk feels that such a change requires them to
assign a new namespace name, which might require changes to
deployed software. Nadia convinces Dirk that they have chosen a
namespace policy that allows changes that will not affect
conformance of existing content and software, and thus no change to
the namespace identifier is required.
Dirk and Nadia have chosen a particular namespace change policy
that allows them to reuse a 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.
Good practice: Document namespace
policy
Format designers SHOULD document change
policies for XML namespaces.
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
possible changes to the namespace in order to promote stable
implementations.
Note that since namespace names are URIs, the party (if any)
responsible for a namespace URI has the authority to decide the
namespace change policy.
Story
Nadia receives a representation data from "weather.example.com"
in an unfamiliar data format. She knows enough about XML to
recognize which XML namespace the elements belong to. Since the
namespace is identified by a URI, she asks her browser to retrieve
a representation of the namespace via that URI. Nadia is requesting
the namespace document.
Nadia gets back some useful data that allows her to learn more
about the data format. Nadia's browser may also be able to use data
optimized for agents automatically (i.e., unattended by a human
overseer) to perform useful tasks on Nadia's behalf, such as
download additional agents to process and render the format.
There are many reasons to provide information about a namespace.
A person might want to:
- understand its purpose,
- learn how to use the markup vocabulary in the namespace,
- find out who controls it,
- 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 "best" data format for creating a
namespace document. Application expectations will influence what
format or formats are used to create a namespace document.
Application expectations will also influence whether relevant
information appears in the namespace document itself or is
referenced from it.
Good practice: Namespace
documents
Resource owners who publish an XML namespace
name SHOULD make available material intended for people to read and
material optimized for agents in order to meet the needs of those
who will use the namespace vocabulary.
For example, the following are examples of formats used to
create namespace documents: [OWL10], [RDDL],
[XMLSCHEMA], and [XHTML]. Each of these formats
meets different requirements described above for satisfying the
needs of a person or agent that wants more information about the
namespace.
Issue: namespaceDocument-8:
What should a "namespace document" look like?
Issue:
abstractComponentRefs-37: Definition of abstract components
with namespace names and frag ids
The section on media
types and fragment identifier semantics discusses the
interpretation of fragment identifiers. Per the previous good practice note on fragment
identifiers, designers of an XML-based format specification
should define the semantics of fragment identifiers in that format.
The XPointer Framework [XPTRFR]
provides a 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 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 fragment identifier
#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.
Unfortunately, there are a number of open issues associated with
finding the element with the ID "abc" in an XML document. In XML,
the quality of "being an ID" is associated with the type of the
attribute, not its name. Consider the following fragment:
<section name="foo">
. Does the
section
element have the ID "foo"? One cannot answer
this question by examining the element and its attributes alone.
Finding the IDs in a document requires additional processing.
- Processing the 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.
- Processing the document with a W3C XML Schema might reveal an
element declaration that identifies the name attribute as an
xs:ID
.
- In practice, processing the document with another schema
language, such as RELAX NG, might reveal the attributes of type ID.
Many modern specifications begin processing XML at the 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, or
PSVI) may successfully 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.
Editor's note: W3C's XML Core Working Group is
investigating the question of fragment identifier semantics.
TAG issue fragmentInXML-28:
Do fragment identifiers refer to a syntactic element (at least for
XML content), or can they refer to abstractions?
TAG issue xmlIDSemantics-32:
How should the problem of identifying ID semantics in XML formats
be addressed in the absence of a DTD? See TAG finding "How
should the problem of identifying ID semantics in XML formats be
addressed in the absence of a DTD?".
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.
Good practice: XML and
text/*
In general, server managers SHOULD NOT assign
Internet Media Types beginning with text/
to XML
representations.
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.
Good practice: XML and character
encodings
In general, server managers SHOULD NOT specify
the character encoding for XML data in protocol headers since the
data is self-describing.
There remain open questions regarding resource representations.
The following sections identify a few areas of future work in the
Web community. The TAG makes no commitment at this time to pursuing
these issues.
Many modern data format specifications include mechanisms for
composition. These mechanisms range from relatively shallow and
limited to relatively deep and sophisticated.
Toward the shallow end of the spectrum, it is possible to embed
text comments in some image formats, such as JPEG/JFIF. Although
these comments are embedded in the containing data, they have
little or no effect on the content of the image.
Towards the deep end, it is possible to compose XML documents
with elements from a variety of namespaces. How these namespaces
interact and what effect an element's namespace has on its
ancestors, siblings, and descendents is not always obvious.
Near the middle of the spectrum, there are container formats
such as SOAP which fully expect to be composed from multiple
namespaces but which provide an overall semantic relationship of
message envelope and payload.
These relationships can be mixed and nested arbitrarily. In
principle, a SOAP message can contain a JPEG image that contains an
RDF comment that references a vocabulary of terms for describing
the image.
TAG issue xmlProfiles-29:
When, whither and how to profile W3C specifications in the XML
Family?
TAG issue mixedUIXMLNamespace-33:
Composability for user interface-oriented XML namespaces
TAG issue xmlFunctions-34:
XML Transformation and composability (e.g., XSLT, XInclude,
Encryption)
TAG issue RDFinXHTML-35:
Syntax and semantics for embedding RDF in XHTML