This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. The latest status of this document series is maintained
at the W3C.
This document has been developed by W3C's Technical Architecture Group
(TAG) (charter).
This draft is an Editor's Draft and some new content has not yet
been reviewed by the TAG. This draft contains substantial revisions
based on discussion at the TAG's 21-23 July face-to-face meeting in
Vancouver. A complete list of changes since the
previous Working Draft is available on the Web.
The TAG has published a number of findings that
address specific architecture issues. Parts of those findings may
appear in subsequent drafts. Please also consult the list of
issues under consideration by the TAG.
This document is intended to inform discussions about issues of
Web architecture. Where current practice conflicts with this
document, this document and related findings are intended to help
the relevant parties resolve their differences. Some parts of this
document may fill in gaps in published specifications or may call
attention to known weaknesses in those specifications.
This draft includes some editorial notes and also references to
open TAG
issues. These do not represent all open issues in the document.
They are expected to disappear from future drafts.
Publication as a Working Draft does not imply endorsement by the
W3C Membership. This is a draft document and may be updated,
replaced or obsoleted by other documents at any time. It is
inappropriate to cite this document as other than "work in
progress."
The latest information regarding patent disclosures
related to this document is available on the Web. As of this
publication, there are no disclosures.
Please send comments on this document to the public W3C TAG
mailing list www-tag@w3.org (archive).
A list of current
W3C Recommendations and other technical documents can be found
at the W3C Web site.
Uniform Resource
Identifiers (URI), defined in "Uniform Resource
Identifiers (URI): Generic Syntax" [URI], are central to Web architecture. URIs
identify (i.e., name) resources.4 Parties who wish to communicate about
something will establish a shared vocabulary, i.e. a shared set of
identifiers with agreed to meanings. This shared vocabulary has a
tangible value: it reduces the cost of communication. The ability
to use common identifiers across communities is what motivates
global naming in Web architecture.
When a representation of one resource
refers to another resource with a URI, a link is formed between the two
resources. The networked information system 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 URI must be assigned to a resource in order for the resource
to be named, shared, or linked to within the information system. It
follows that any 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, or annotate
it.
Principle
Use URIs: A URI SHOULD be assigned to each
resource that is intended to be identified, shared, or described by
reference.5
Web architecture does not constrain resources to be uniquely
named; a resource may be assigned more than one URI.
There are many benefits to assigning a URI to a resource. Some
are by design (e.g., linking, book marking, and caching), others
(e.g., global search services) were not predicted.6
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". Two suggested definitions for "on the Web" are "is
identified by a URI" and "is identified by a URI and at least one
representation is available for retrieval."
The most straightforward way of establishing that two parties
are referring to the same resource is to compare the URIs they are
using, as character strings. In section 6 of [URI], determination of equivalence or difference of
URIs is based on string comparison.
Good practice
URI characters: If a URI has been assigned to
a resource, Web components SHOULD refer to the resource using the
same URI, character for character.
The term "character" refers to URI characters as defined section
2 of [URI].
Although it is possible to determine that two URIs are
equivalent, it is generally not possible by inspection of two URIs
to be sure that they identify different resources. Applications may
apply rules beyond basic string comparison (e.g., for "http" URIs,
the authority component is case-insensitive) to reduce the risk of
false negatives and positives. Please refer to section 6.3 of [URI] for more information about
reducing the risk of false positives and negatives.
Web components that reach conclusions based on comparisons done
through means other than those licensed by relevant specifications
take responsibility for any problems that result. For instance,
components should not assume that
"http://weather.example.com/Oaxaca" and
"http://weather.example.com/oaxaca" identify the same
resource, since none of the specifications involved states that the
path part of an "http" URI is case-insensitive.
To help parties know when they are referring to the same
resource, it follows that URI producers should be conservative
about the number of different URIs they produce for the same
resource. For instance, the parties responsible for
weather.example.com have no reason to use both
"http://weather.example.com/Oaxaca" and
"http://weather.example.com/oaxaca" to refer to the
same resource; components will not detect the equivalence
relationship by following specifications.
There may be other ways to establish that two parties are
identifying the same resource that are not based on string
comparison; see the section on future directions for determining that two URIs
identify the same resource.
Although it is tempting to guess at the nature of a resource by
inspection of a URI that identifies it, this is not licensed by
specifications; this is called URI opacity. In our travel scenario, the example URI
("http://weather.example.com/oaxaca") suggests that
the identified resource has something to do with the weather in
Oaxaca. 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." See the section on retrieving a
representation for information about how components convey
information about a resource.
The more resource metadata is included in a URI, the more
fragile the URI becomes (e.g., sensitive to changes in
representation).
Editor's note: When finding
available on URI opacity, link from here. See TAG issue metadataInURI-31.
There is a related principle that has not yet been captured: don't
restrict (e.g., through specifications) the URI space allotted to
resource owners. See TAG issue siteDate-26:
Web site metadata improving on robots.txt, w3c/p3p and favicon
etc.
In the URI "http://weather.example.com/", the
"http" that appears before the colon (":") is a URI scheme name.
The name refers to a URI scheme specification, which explains how
to assign identifiers within that scheme. The URI syntax is thus a
federated and extensible naming system wherein each scheme's
specification may further restrict the syntax and semantics of
identifiers within that scheme. Furthermore, the URI scheme
specification specifies how a component can dereference the URI.
Several URI schemes incorporate information systems that
pre-date the Web into the URI syntax:
- mailto URIs identify7 mailboxes:
mailto:nobody@example.org
- ftp URIs identify ftp files and directories:
ftp://example.org/aDirectory/aFile
- news URIs identify USENET newsgroups:
news:comp.infosystems.www
- tel URIs identify terminals on the telephone network:
tel:+1-816-555-1212
Other URI schemes have been introduced since the advent of the
Web, including those introduced as a consequence of new protocols.
Examples of such URI schemes include:
- http URIs:
http://www.example.org/something?with=arg1;and=arg2
- ldap URIs:
ldap://ldap.itd.umich.edu/c=GB?objectClass?one
- URNs:
urn:oasis:SAML:1.0
The Internet Assigned Numbers Authority
(IANA) maintains a registry [IANASchemes] of mapping between URI scheme
names and scheme specifications. For instance, the IANA registry
indicates that the "http" scheme is defined in [RFC2616]. The process for registration of new
URI schemes 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 introduction of new URI schemes is
high.
Good practice
New URI schemes: Authors of
specifications SHOULD NOT introduce a new URI scheme when an
existing scheme specifies 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 a
component dereferences such a URI, if what really happens is that
HTTP GET is invoked to retrieve an HTML representation of the
resource, then an "http" URI would have sufficed. If a URI scheme
exists that meets the needs of an application, designers should use
it rather than invent one. Furthermore, designers should expect
that it will prove useful to be able to share a URI across
applications, even if that utility is not initially evident.
If the motivation behind registering a new scheme is to allow a
component 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.
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.
When navigating within the XHTML data that Dan receives as a
representation of the resource identified by
"http://weather.example.com/oaxaca", Dan 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 component of a URI allows indirect
identification of a secondary resource by
reference to a primary resource and additional identifying
information. The secondary resource may be some portion or subset
of the primary resource, some view on representations of the
primary resource, or some other resource. The URI that identifies
the secondary resource consists of the URI of the primary resource
with the additional identifying information as a fragment
identifier. 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 instance of "F" identify secondary resources,
then
- the URI for the secondary resource identified within an
instance of "F" by fragment identifier "fragid" is "U#fragid".
For URI schemes that do specify the use of fragment identifiers,
the syntax and semantics of those identifiers are defined by the
set of representations
that might result from a retrieval action on the primary
resource. The presence of a fragment identifier component in a URI
does not imply that a retrieval action will take place.
Interpretation of the fragment identifier during a retrieval
action is performed solely by the user 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 effect on fragment identifiers
and that redirection (in HTTP [RFC2616], for example) does not account for
them.
Suppose that the authority responsible for "weather.example.com"
provide a visual map of the meteorological conditions in Oaxaca as
part of the representation served for
"http://weather.example.com/oaxaca". They might encode
the same visual map in a number of image formats to meet different
needs (e.g., they might serve PNG, SVG, and JPEG/JFIF). Dan's
browser and the server engage in HTTP content negotiation, so that
Dan receives the best image format his browser can handle or the
image format he usually prefers. The URI
"http://weather.example.com/oaxaca/map#zicatela"
refers to a portion of the weather map that shows the Zicatela
Beach, where Dan intends to go surfing. Clients can do something
useful with the fragment identifier and the SVG representation,
since SVG defines fragment identifier semantics.
On the other hand, it is an error when the authority responsible
for a resource publishes a URI with a fragment identifier and
representations of the resource do not have consistent fragment
identifier semantics. Thus, the authority responsible for
"http://weather.example.com/oaxaca/map#zicatela"
creates an error condition by making available PNG and JPEG/JFIF
representations since those format specifications do not define
fragment identifier semantics.
Good practice
Content negotiation with fragments:
Authorities responsible for minting a URI with a fragment
identifier and who use content negotiation to serve multiple
representations of the identified resource SHOULD NOT serve
representations with inconsistent fragment identifier
semantics.
Fragment identifier semantics may differ among format
specifications. See related TAG issues httpRange-14
and RDFinXHTML-35
and
abstractComponentRefs-37.
To dereference a URI means to access the resource identified by
the URI. Access may take many forms, including retrieving a representation
(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).
When accessing a resource, a component applies relevant
specifications in succession, beginning with the specification of
the context in which the URI is found (e.g., a format or protocol
specification, or an application). Any one of these specifications
may define more than one access mechanism (e.g., the HTTP protocol
defines a number of access methods, including GET,
HEAD, and POST). Note that the information governing the choice of
access mechanism may be found in the context, not the URI itself
(e.g., the choice of HTTP GET v. HTTP HEAD). The TAG finding
"URIs,
Addressability, and the use of HTTP GET and POST."
discusses issues surrounding multiple access mechanisms and the
relation to URI addressability.
Some URI schemes (e.g., the URN scheme [RFC 2141]) do not define dereference
mechanisms.
TAG issue metadataInURI-31:
Should metadata (e.g., versioning information) be encoded in
URIs?
One of the most important actions involving a resource is to
retrieve a representation of it (for example, by
using HTTP GET; HTTP POST does not retrieve a
representation of the identified resource). The authority
responsible for assigning a URI to a resource determines which
representations are used for interaction with the resource. The
representations communicate all or part of the state of the
resource.
Good practice
Resource descriptions: Owners of
important resources SHOULD make available representations of those
resources.
As an example of representation retrieval, suppose that the URI
"http://weather.example.com/budapest" is used within
an a element of an SVG document. The sequence of
specifications applied is:
- The SVG 1.0 Recommendation [SVG10], which 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 attribute
xlink:href is defined in section 5.4
of the XLink 1.0 [XLink10]
specification 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".
- To find out what specification defines the "http" scheme, we
look up the mapping in [IANASchemes]; the "http" URI scheme is
defined in the HTTP/1.1 specification (RFC 2616 [RFC2616], section 3.2.2).
- The HTTP/1.1 specification defines several access mechanisms.
In this SVG context, the user agent employs the GET method (defined
in section 9.3 of [RFC2616]) to
retrieve the representation. The HTTP/1.1 specification explains
how the server constructs the response (section 6 of [RFC2616]), including the
'Content-Type' field8. Section 1.4 states "HTTP
communication usually takes place over TCP/IP connections." Though
not shown in this example, the user agent would continue this
process by implementing those specifications.
- The user agent interprets the returned representation according
to the value of the 'Content-Type' field, by looking up which
specification defines the Internet Media Type in the [MEDIATYPEREG] registry.
Note that, in general, one cannot determine the Internet Media
Type(s) of representation(s) of a resource by inspecting a URI for
that resource. For example, do not assume that all representations
of "http://example.com/page.html" are 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 PNG image
representation.
Dan's retrieval of weather information qualifies as a "safe"
interaction; a safe interaction is one
where the user 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; the user may be held
responsible for the consequences of these interactions. Unsafe
interactions include subscription 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 software programs
(e.g., search engines and browsers that pre-cache data for the
user) can follow links safely. Users (or components acting on their
behalf) do not commit themselves to anything by querying a resource
or following a link.
Principle
Safe retrieval: Components do not incur
obligations by retrieving a representation.
For instance, it is incorrect to publish a link (e.g.,
"http://example.com/oxaca/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."
The value of a URI increases with the predictability of
interactions using that URI.
Good practice
URI persistence: Parties responsible for a
URI SHOULD service that URI predictably and consistently.
Service breakdowns include:
- No service available (i.e., dereferencing fails).
- Inconsistent representations served. Note the difference
between a resource owner changing representations predictably in
light of the nature of the resource (e.g., the weather in Oaxaca
changes) and the owner changing representations arbitrarily.
- Improper use of content negotiation, such as serving two images
as equivalent through HTTP content negotiation, where one image
represents a square and the other a circle.
There are strong social expectations that once a URI identifies
a particular resource, it should continue indefinitely to refer to
that resource; this is called URI persistence. URI
persistence is always a matter of policy and commitment on the part
of authorities servicing URIs rather than a constraint imposed by
technological means.
URI
ambiguity refers to the use of the same URI to refer to
more than one distinct thing.
Good practice
URI ambiguity: Avoid URI ambiguity.
Ambiguous use of a URI can be costly. Suppose that one division
of Large Company, Inc. maintains data about company Web pages,
including who created them and when. Another division in the
company maintains data about companies, including who created them
and when. The second data set uses the URIs of the organization's
home page as though it was the URI of the organization itself. When
the two data sets are merged, the reuse of the URI causes
information about companies to be merged with that of the home
pages, resulting in potentially costly nonsense.
URI ambiguity differs from "indirect identification," which is
common. For example, one may identify meeting participants by using
their email addresses (e.g., "joe@example.com"). In
this case, all parties know that they are using a mailbox
identifier to indirectly identify the person. In terms of Web
architecture, "mailto:joe@example.com" still
identifies a mailbox, not a person.
As another example of URI ambiguity, saying that the URI
"http://www.example.com/moby" identifies "Moby Dick"
can lead to confusion because this might be interpreted as any one
of the following very distinct resources: a particular printing of
this work, 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.
HTTP [RFC2616] has been
designed to help service URIs. For example, HTTP redirection (via
some of 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 would not be required to define new
URIs for each new format specification that is supported, as would
be the case with protocols that don't support content negotiation,
such as FTP.
For more discussion about URI persistence, refer to [Cool].9
As we have seen, identification of a resource is distinct from
interaction with that resource. 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: A building might have a policy that the public
may only enter via the main front door, and only during business
hours. People employed in the building and in making deliveries to
it might use other doors as appropriate. Such a policy would be
enforced by a combination of security personnel and mechanical
devices such as locks and pass-cards. One would not enforce this
policy by hiding some of the building entrances, nor by requesting
legislation requiring the use of the front door and forbidding
anyone to reveal the fact that there are other doors to the
building.
In the travel scenario,
imagine that Dan and Norm both subscribe to the
"weather.example.com" newsletter. Dan wishes to point out an
article of particular interest to Norm, using a URI. The authority
responsible for "weather.example.com" can offer Dan and Norm 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, none of which
relies on hiding or suppressing URIs for those resources. For more
information on identification and access control, please refer to
the TAG finding "'Deep
Linking' in the World Wide Web."
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 -- or at least claim --
formally 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.
In the travel scenario, Dan
retrieves a representation from the weather site
"http://weather.example.com/oaxaca". He then follows
the link labeled "satellite image" in the representation data and
retrieves a representation of a secondary resource, a satellite
photo of the Oaxaca region.
The link to the satellite image is an HTML link encoded as
<a href="http://example.com/satimage/oaxaca">satellite
image</a>. Dan's browser analyzes the URI and
determines that its scheme
is "http". 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. Some of the headers (for example,
'Transfer-encoding: identity', which indicates that no compression
has been applied) are descriptive of the message. The remainder of
the headers and the message body together comprise a representation of the
resource identified by
"http://example.com/satimage/oaxaca".
The browser reads the headers, learns from the 'Content-Type'
field that the Internet Media Type of the representation data is
"text/jpeg", reads the sequence of octets that comprises the
representation data, and renders the image.
Dan decides to book a vacation to Oaxaca at
"booking.example.com." He completes a series of HTML forms and is
ultimately asked for credit card information to purchase the
airline tickets. He provides this information in another HTML form.
When he presses the "Purchase" button, his 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 since Dan 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 Dan's browser that
contains a representation of the results of Dan's request. The
representation data is in HTML so that it can be saved or printed
out for Dan'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.
Web components exchange information via messages that are
constructed according to a non-exclusive set of messaging protocols
(e.g., HTTP, FTP, NNTP, SMTP10, etc.). A message exchanged between Web
components is an octet sequence consisting of:
- Message
data: Electronic data such as a resource representation.
- Message
metadata: Metadata about the message, such as the HTTP
Server field, information about how message data has been encoded
for transfer (e.g., using gzip), or the request method. A message
may even include "meta-metadata" (for message-integrity
checks).
This section will describe the architectural principles and
constraints regarding interactions between components, including
such topics as network protocols and interaction styles, along with
interactions between the Web as a system and the people that make
use of it. This will include the role of architectural styles, such
as REST and SOAP, and the impact of meta-architectures, such as Web
Services and the Semantic Web.
Good practice
Understand REST: Designers of protocols
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
- limited, uniform set of verbs
3.3. Moved here from other sections temporarily
- Introduce notions of client and server? Relation of client to
agent and user agent. Relation of server to resource owner.
- Don't invent a new protocol when one exists that gets the job
done. You'd have to replicate the caching structure, and the social
behavior. Also, you are likely to make the same mistakes made by
the original protocol designers.
- When you create a new protocol, you may want to create a new
URI scheme that corresponds to it.
The representation of the state
of a resource is an octet sequence consisting of:
- Representation data:
Electronic data expressed in one or more data formats used separately or in
combination. A data format (e.g., XHTML, CSS, PNG, XLink, RDF/XML,
and SMIL animation) is defined by a format specification. A
format specification governs the handling of fragment identifiers.
- Representation
metadata: Metadata about the representation data, such as
the Internet Media Type11 (defined in RFC 2046 [RFC2046]). The Internet Media Type
governs the authoritative interpretation of representation data.
Note: The terms "data format" and "media type" are
often used interchangeably. 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..."
Web components use representations to modify as well as retrieve
resource state.
The first data format used to build representations was HTML.
Since then, data formats for the Web have flourished. The Web
architecture does not constrain which data formats can be used to
build representations. This flexibility is important, since there
is continuing progress in the development of new data formats for
new applications and the refinement of existing ones.
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.
Successful communication between two parties about a piece of
information relies on shared understanding of the meaning of the
information. Thousands of independent parties can identify and
communicate about a Web resource. To give these parties the
confidence that 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.
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) Dan 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 Dan 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 Dan made the request. Since the weather in Oaxaca changes,
Dan 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 (for example, due to
security issues).
Principle
Authoritative server metadata: User agents
MUST NOT silently ignore authoritative server metadata.
Thus, for example, if the parties responsible for
"weather.example.com" mistakenly label the satellite photo of
Oaxaca as "image/gif" instead of "image/jpeg", and if Dan's browser
detects a problem, Dan's browser must not silently ignore the
problem and render the GIF image. Dan's browser can notify Dan of
the problem, notify Dan and take corrective action, etc. Of course,
user agent designers should not ignore usability issues when
handling this type of error; notification may be discreet, and
handling may be tuned to meet the user's preferences.
See the TAG finding "Client
handling of MIME headers" for more in-depth discussion
and examples.
Furthermore, server managers 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.
For a data format to be usefully interoperable between two
parties, the parties must have a shared understanding of its syntax
and semantics. This is not to imply that a sender of data
can count on constraining its treatment by a receiver; simply that
making good use of electronic data usually requires knowledge of
its designers' intentions.
Good practice
Format specification availability: To
promote the interoperability of a Web data format, there SHOULD be
a stable, normative specification for it that is a widely available
Web resource.
Good practice
Media type registration: A format
specification SHOULD have an officially registered Internet Media
Type (see the [MEDIATYPEREG] registry).
See TAG finding "Internet Media
Type registration, consistency of use" for more
information.
Good practice
Specified fragment identifier semantics: A
format specification SHOULD define the syntax and semantics of
fragment identifiers.
Although the Web architecture allows for the deployment of new
data formats, the creation and deployment of new formats (and
software able to handle them) can be very expensive. Thus, before
inventing a new data format, designers should carefully consider
re-using one that is already available. For example, if a format is
required to contain human-readable text with embedded hyperlinks,
it is almost certainly better to use HTML for this purpose than to
invent a new format.
Errors, of course, occur in the deployment of software and data.
The degree to which errors are tolerated varies depends on
application context.
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.
Good practice
Specify error handling: Format
specification designers SHOULD specify component 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.
When designing specifications that address independent functions
of a system, references between the specifications are in general
harmful since such references impede the independent evolution of
the specifications.
For example, it is a strength of XML that XPath cannot query the
HTTP header. It is a strength of HTTP that it does not refer to
details of the underlying TCP to the extent that it cannot be run
over a different transport service. Similarly, the RDF data graph
has a significance that is independent of the actual
serialization.
Sometimes it is necessary (and even good for given application)
to cross specification boundaries. For example, it is good for an
HTTP component to be aware of TCP speeds and round trip times to
different mirror servers in order to optimize the choice of
server.
Good practice
Identify features that peek: Format
specification designers SHOULD clearly identify the features of a
format specification that peek across specification boundaries.
A textual data format is one in which the data is specified as a
linear sequence of characters. HTML, Internet e-mail, and all
XML-based 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
software in those cases where they can be loaded into memory and
used with little or no conversion.
Textual formats are often more portable and interoperable, since
there are fewer choices for representation of the basic units
(characters), and those choices are well-understood and widely
implemented.
Textual formats also have the considerable advantage that they
can be directly read and understood by human beings. This can
simplify the tasks of creating and maintaining processing software,
and allow the direct intervention of humans in the processing chain
without recourse to tools any more complex than the ubiquitous text
editor. Finally, it simplifies the necessary human task of learning
about new data formats (the "View Source" effect).
It is important to emphasize that intuition as to such matters
as data size and processing speed are not a reliable guide in data
format design; quantitative studies are essential to a correct
understanding of the trade-offs.
TAG issue binaryXML-30:
Effect of Mobile on architecture - size, complexity, memory
constraints. Binary infosets, storage efficiency.
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.
Composition is related to but distinct from the question of
whether a data format is intended as a final form. For example, one can imagine
embedding SVG in a JPEG image thus combining final-form and
reusable components, whereas a SOAP envelope might provide nothing
more than a container for a particular payload that has no
presentation form at all.
TAG issue xmlProfiles-29:
When, whither and how to profile W3C specifications in the XML
Family?
TAG issue mixedUIXMLNamespace-33:
Composability for user interface-oriented XML namespaces
TAG issue xmlFunctions-34:
XML Transformation and composability (e.g., XSLT, XInclude,
Encryption)
TAG issue RDFinXHTML-35:
Syntax and semantics for embedding RDF in XHTML
A format is extensible if instances of the
format can include terms from other vocabularies. For example, XML
and XML Namespaces allow format designers to create and combine
vocabularies.
Good practice
Format extensibility: Format designers
should create extensible formats.
Versioning is the term for the evolution of formats and
documents. Versioning is achieved through extensibility mechanisms
and format redefinition. When a format definition changes (e.g., by
addition or removal of element or attribute definitions), this
creates a new version of the format. When an instance of a format
includes elements from another data format, this creates an
extension of the instance; the original format definition has not
changed. An example is a SOAP message with a header block; this is
called a SOAP extension, not a new version of the SOAP format.
The following terms define important relationships among
different versions of a format:
- Compatible formats
- Format version M is compatible with format version N if
components designed to process all instances of M can also process
all instances of N. The compatibility relationship is not always
symmetric.
- Forwards
compatibility
- Format version M is forwards compatible with respect to format
version N if M is compatible with N and M predates N.
- Backwards
compatibility
- Format version M is backwards compatible with respect to format
version N if M is compatible with N and N predates M.
Good practice
Format compatibility: Format designers
SHOULD define extensibility models that allow forwards compatible
and backwards compatible changes.
Naturally, even if M and N are compatible but different versions
of a format, components will process instances of them differently.
For instance, if format version M is forwards compatible with
format version N, M processors that encounter N instances might
handle unknown elements by ignoring them entirely, or by ignoring
element tags but continuing to process element content. Different
format specifications may require different compatibility
behavior.
Good practice
Compatibility behavior: Format
designers SHOULD define expected behavior when components designed
to process one version of a format encounter a compatible version
of the format.
In some cases, format designers require that new features be
supported (i.e., not ignored). In this case, the new version of the
format (N) may be backwards compatible with the earlier version
(M), but M is not forwards compatible with N. The SOAP 1.2
Recommendation [SOAP12], for
example, defines the mustUnderstand attribute in section
5.2.3.
For more information on format extensibility, refer to "Web
Architecture: Extensible Languages" [EXTLANG].
Replacement text from C. Lilley expected.
In many cases, the information encoded in a data format is
logically separable from the choice of ways in which it may be
presented to a human, and the modes of interaction it may
support.
While such separation is, where possible, often advantageous, it
is clearly not always possible and in some cases not desirable
either.
Final-form data formats are not designed to allow modification
or uses other than that intended by their designers. An example
would be PDF, which is designed to support the presentation of page
images on either screen or paper, and is not readily used in any
other way. XSL Formatting Objects (XSL-FO) share this
characteristic.
XHTML, on the other hand, can be and is put to a variety of uses
including direct display (with highly flexible display semantics),
processing by network-sensitive Web spiders to support search and
retrieval operations, and reprocessing into a variety of derivative
forms.
There are many cases where final-form is an application
requirement; representations which embody legally-binding
transactions are an obvious example. In such cases, the use of
digital signatures may be appropriate to achieve immutability.
On the other hand, where such requirements are not in play,
representations that are re-usable and re-purposable are in general
higher in value, particularly in the case where the information's
utility may be long-lived.
See also TAG issues Issue formattingProperties-19
and contentPresentation-26.
One of the greatest strengths of HTML as a format is that it
allows authors to embed cross references (hyperlinks). The
simplicity of <a href="#foo"> as a link to
foo 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.
Simple, single-ended, single-direction, inline links are not the
most powerful linking paradigm imaginable. They are very easy to
understand, however, and they can be authored by individuals (or
other components) that have no control or write access to the other
end point.
More sophisticated linking mechanisms have been invented for the
Web. XPointer allows links to address content that does not have an
explicit, named anchor. XLink allows links to have multiple ends
and to be expressed either inline or in "link bases" stored
external to any or all of the resources identified by the links it
contains.
All of the current common linking mechanisms identify resources
by URI reference.
Good practice
Link mechanisms: Format specification
designers SHOULD provide mechanisms for identifying links to other
resources and to portions of representations (via fragment
identifiers). Allow Web-wide linking, not just internal document
linking.
For formats based on XML, format designers should examine XLink
and the XPointer framework for inspiration. To define fragment
identifier syntax, use at least the XPointer Framework and XPointer
element() Schemes.
TAG issue: What is the scope of using XLink? xlinkScope-23.
If a future revision of RFC 3023 identifies the XPointer
Framework, element(), and perhaps other ancillary schemes as the
fragment identifier syntax for XML documents, authors will be able
to rely on at least those schemes for all XML documents.
Good practice
URI genericity: Format specification
designers SHOULD allow authors to use URIs without constraining
them to a limited set of URI schemes.
Good practice
QName caution: Format specification
designers MAY use Qualified Names (QNames) for identifiers in
representation data, but should be aware of the limitations and
interoperability risks associated with them.
See the TAG finding "Using QNames as
Identifiers in Content" for more information. See also
TAG issues rdfmsQnameUriMapping-6
and qnameAsId-18.
Many representations are encoded using data formats based on XML
1.0 [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. For example, an audio or video format is
unlikely to be well suited to representation in XML. Design
constraints that would suggest the use of XML include:
- Explicit representation of 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.
Editor's note: Which XML
Specifications make up the XML Family?
The authority responsible for "weather.example.com" realize that
they can provide more interesting representations by creating
instances that consist of elements defined in different published
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 combined XML
formats)? "Namespaces in XML" [XMLNS] provides a mechanism for establishing a
globally unique name that can be understood in any context.
The "absolute" form 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.
The most significant technical drawback to using namespaces is
that they do not interact well with DTDs. DTDs perform validation
based on the lexical form of the name, making prefixes semantically
significant in ways that are not desirable. As other schema
technologies become widely deployed, this drawback will diminish in
significance.
Dan receives a representation from "weather.example.com" in an
unfamiliar data format. He knows enough about XML to recognize
which XML namespace the elements belong to. Since the namespace is
identified by a URI, he asks his browser to retrieve a
representation of the namespace via that URI. He gets back some
useful data that allows him to learn more about the data format;
this is called a namespace document.
Dan's browser may also be able to use machine-readable data
automatically to perform useful tasks on Dan's behalf, such as
download additional software components to process and render the
format.
There are many reasons why a person or other component might
want more information about the 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 namespace document should also support the automatic retrieval
of other Web resources that support the processing markup from this
vocabulary. Useful information to processors includes:
- schemas, to use for validation,
- style sheets, to use for presentation,
- ontologies, to use for making inferences, or
- any number of other application-specific details.
Good practice
Namespace documents: XML namespace
designers SHOULD make available human-readable and machine-readable
material to meet the needs of those who will use the namespace
vocabulary.
In general, there is no "best" data format for encoding a
namespace document. See the section on future work regarding namespace document formats for more
information.
Issue: namespaceDocument-8:
What should a "namespace document" look like?
Issue:
abstractComponentRefs-37: Definition of abstract components
with namespace names and frag ids
Suppose that the URI "http://example.com/oaxaca"
defines a resource with representations encoded in XML. What, then,
is the interpretation of the URI
"http://example.org/oaxaca#weather"?
The URI specification [URI]
makes it clear that the interpretation depends on the media type of
the representation data. 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]) as there is no
normative specification of fragment semantics in this case.
It is common practice to assume that when an element has an
attribute that is declared in a DTD to be of type ID, then the
fragment identifier #abc identifies the element which
has an attribute of that type whose value is "abc".
However, there is no normative support for this assumption and it
is problematic in practice, since the only defined way to establish
that an attribute is of type ID is via a DTD, which may not exist
or may not be available.
TAG issue fragmentInXML-28:
Do fragment identifiers refer to a syntactic element (at least for
XML content), or can they refer to abstractions? See TAG issue.
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.
Good practice
XML and "text/*": In general, Internet Media
Types beginning with text/ SHOULD NOT be assigned to
XML representations.
These Internet Media Types create two problems: First,
intermediaries in the Web are allowed to "transcode", i.e., convert
one character encoding to another. Since XML documents are designed
to allow them to be self-describing, and since this is a good and
widely-followed practice, any such transcoding will make the
self-description false.
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.
In the case of XML, since it is 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.
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.
The Resource Directory Description Language [
RDDL] is a proposal under discussion in the
community for a variant of XHTML optimized for the construction of
namespace documents which meet the goals described in this section.
Note, however, that RDDL (or a format like it) is no more
universally correct than any other type of representation.
Namespace developers should give careful consideration to choosing
the most appropriate format for their application, keeping in mind
that both human- and machine-readable information is useful.