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.
The information in the Web and the technologies used to represent that
information change over time. Some examples of successful technologies
designed to allow change while minimizing disruption include: The fact URI
schemes are indepedently specified, The use of an open set Internet media
types in mail and HTTP to specify document interpretation; Then The
separation of the generic XML grammar and the open set of XML namespaces of
element and attribute names; Cascading Style Sheets (CSS) rules for handling
unknown style properties and property values; the SOAP extensibility model,
and user agent plugins.
The following applies to languages, in particular the specificatons of
data formats, of message formats and URIs.
One language is a subset of another (sometimes called a
profile) if and only if any document in the first language is also
a valid document in the second language and has the same meaning in the
second language.
The extension of a language is a new language which
is a superset of the original language.
Clearly, an extension language is better than an incompatible language,
but in practice greater compatability is needed. Ideally, an instance of the
superset language, in many cases can be safely and usefully processed as
though it were in the subset language. Extensability the property
of the orginal langauge that allows this. The original language design can
accomplish extensability by defining, for predicable unknown extensions, the
handling by implementations -- for example that they be ignored (in some way)
or should be considered errors.
Even with good extensability, any new version has its advantages and
disadvantages. 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).
Orthogonal design is when a language is designed by two (or more)
specifications that reference each other through the definition of a single
(or small number) of terms.
Example: XML schema is defined as a schema language where the concept
"datatype" is filled by a basically independent list of data types. The
schema language can be extended by adding new datatypes.
Clearly, othogonality in design aids extensability.
See also section 4.3
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. Compatability was discussed in Section 1.2.
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.
Extensibility is not free. Providing hooks for extensibility is another
requirement that must be factored into the costs of language design.
Experience suggests that the long term benefits generally outweigh the
costs.
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.
Qualified names were introduced by [XML Namespaces]. They were defined for
element and attribute names and provide a mechanism for concisely identifying
a URI/local-name pair. Other specifications, starting with [XSLT], have taken
QNames and employed them in contexts other than element and attribute
names.
Specifically, QNames have been used in attribute values and element
content. Some specifications use QNames as shortcuts for unique identifiers
derived from a URI/local-name pair that have no relationship to element or
attribute names. Using a QName as a shortcut for a URI/local-name pair is
often convenient, but it carries a price. There is no single, accepted way to
convert QNames into URI/local-name pairs or vice versa. The identification
mechanism for the web is the URI.
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
