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).
The primary change in this draft is the development of section
2. A list of
changes in this document is available.
This draft remains incomplete; sections 1, 2, and 3 are the most
developed; 4 the least. 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 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.
The World Wide Web (or, Web) is a networked information system
consisting of agents (programs acting on behalf of a person,
entity, or process) that exchange information. This document
describes the three architectural divisions of this information
system:
- Identification.
Agents identify objects in the system, called "resources," with
Uniform Resource Identifiers (URIs).
- Representation.
Agents represent, describe, and communicate resource state with a
nonexclusive set of data formats, used separately or in combination
(e.g., XHTML, CSS, PNG, XLink, RDF/XML, SMIL animation).
- Interaction. Agents
exchange representations via a non-exclusive set of protocols,
including HTTP, FTP, and SMTP1
The most comment user experience on the Web today is summarized
by the following interaction loop:
- Starting with a URI, the user (via a user agent) requests a
representation of the identified resource. The protocol chosen for
the request determines the structure and capabilities of the
request (and response).
- If the request is successful, the response provides the user
agent with a representation, consisting of data and metadata (such
as the Internet Media Type of the data). The data may include URIs
so the process can be repeated.
Here's a more detailed scenario: Suppose Dan is planning a
vacation to Mexico and wishes to learn about the weather in Oaxaca.
In a glossy travel magazine, Dan finds a URI for a Web site that
reports on the weather in Oaxaca. This resource is identified by
the URI http://weather.example.com/oaxaca. This is an
"HTTP URI" (see the section on URI schemes), so:
- The entity responsible for
weather.example.com has
the authority to make available representations of this resource;
weather.example.com is the authority component of an HTTP URI, as
defined in [URI]. The people
managing weather.example.com set up a server to handle
requests for representations of the resource in question.
- The HTTP protocol [RFC2616]
is the protocol used to request a representation.
Dan's client sends a request to a server at
weather.example.com, with the URI
http://weather.example.com/oaxaca. The representation
Dan receives (and whether he receives one at all) depends on a
number of factors, including:
- Whether the people managing
weather.example.com
respond to requests at all;
- Whether the people managing
weather.example.com
make 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 people managing
weather.example.com have
provided more than one representation (in different formats such as
HTML, PNG, or RDF, in different languages such as English and
Spanish, etc.), the result representation may depend on negotiation
between the client 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.
If all goes well, the representation sent back to Dan's client
includes data (say, an HTML document) and metadata about that data
(including the Internet Media Type text/html). Dan's
client renders the resulting HTML, which includes URIs, and Dan can
follow a link to start the process again.
Throughout this document, we elaborate on this scenario to
introduce and illustrate architectural principles.
The intended audience for this document includes:
- Participants in W3C Activities,
- Other groups and individuals developing technologies to be
integrated into the Web.
- Implementers of W3C specifications, and those who use the
resulting products.
The authors have made every effort to keep this document terse
but to illustrate important points through examples. The TAG
expects that additional documents such as the TAG findings will
provide more background, motivation, and examples.
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.
The architecture described in this document is principally the
result of experience. There has been some theoretical and modeling
work in the area of Web Architecture, notably Roy Fielding's work
on "Representational State Transfer" [REST].
The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used
in accordance with RFC 2119 [RFC2119].
Some of the principles, practice, etc. may conflict with current
practice, in which case education and outreach will be required to
improve on that practice. Other items may fill in gaps in published
specifications or may call attention to known weaknesses in those
specifications.
The motivation behind some good practice notes is economic:
there is a benefit to doing things a standard way and a cost to
doing things differently. For instance:
- It is prohibitively expensive to use an identification
mechanism other than URIs.
- It is quite costly to introduce a new URI scheme.
- It is costly to introduce a new protocol or format.
This document promotes reuse of existing standards when
suitable, and gives some guidance on how to innovate (when
necessary) in a manner consistent with the Web architecture.
This document focuses on the architecture of the Web. The
authors assume the reader is familiar with the rationale for some
of the general design principles: minimal constraints (fewer rules
makes the system more flexible), modularity, minimum redundancy,
extensibility, simplicity, and robustness.
Other groups inside and outside W3C are writing down principles
related to specialized aspects of Web architecture, including
accessibility, internationalization, device independence, and Web
Services. The section on Architectural Specifications includes some
references.
Web architecture starts with Uniform Resource Identifiers (URI),
whose generic syntax is defined by "Uniform Resource Identifiers
(URI): Generic Syntax" [URI]. The
Web relies on a worldwide agreement to follow the rules of URIs so
that we can refer to things on the Web, access them, describe them,
and share them.
URIs identify resources. When people (through representations) refer to a resource
with a URI, a link is formed. The networked information system is
built of linked resources, and the large-scale effect is a shared
information space. The value of the Web increases with the number
of linked resources (the "network effect"). The value of a resource
also increases when it is identifiable on the Web.
Principle
Use URIs: All important resources SHOULD be
identified by a URI.2
There are many benefits to making resources identifiable by URI.
Some are by design (e.g., linking, bookmarking, and caching), while
others have arisen naturally (e.g., global search services).3
Communication requires that two parties have a way of knowing
they are referring to the same resource. On the Web, if two parties
use the same URI, the parties are referring to the same resource.
Section 6 of [URI] discusses URI
comparison and the determination of URI equivalence. In general,
rules for determining URI equivalence come from more than on
specification, usually the URI specification, a URI scheme specification, and a protocol
specification. Depending on the application, a client may invest
more processing effort to reduce the likelihood of a false negative
(i.e., two URIs are equivalent but that was not detected).
Clients must not make assumptions about URI equivalence that are
not borne out by the relevant specifications. For instance, clients
must 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 that the path part of the URI is case-insensitive. Web servers
may vary in how they are configured to handle case-sensitivity.
Though it is possible to determine that two URIs are equivalent,
it is never possible to be sure that two URIs identify different
resources. Web architecture does not constrain resources to be
uniquely named.
Good practice
Spelling URIs: If you want to refer to a
resource, and you have been provided with a URI for that purpose,
you SHOULD use the spelling of the URI as it was originally
provided.
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, a URI producer should not advertise
(without cause) that http://weather.example.com/Oaxaca
and http://weather.example.com/oaxaca refer to the
same resource, as clients will not detect the equivalence
relationship. See section 6.3 of [URI] for further advice on how to reduce the risk
of false negatives.
Note that a URI does not, in general, provide information about
the nature of the resource it identifies. 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.
Although short, meaningful URIs benefit people, agents must not
rely on the URI string to communicate the meaning of a resource. 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 old car." See the section on retrieving a
representation for information about how the meaning of a
resource is conveyed.
Editor's note: When finding
available on URI opacity, link from here.
Each URI begins with a scheme name (the string before the first
":") that refers to a specification for assigning identifiers
within that scheme. As such, the URI syntax is a federated and
extensible naming system wherein each scheme's specification may
further restrict the syntax and semantics of identifiers using that
scheme. For instance, a URI scheme might specify the type of
resource identified by such URIs, the desired persistence of such
URIs, or a default character encoding for URIs of that scheme.
Furthermore, the URI scheme specification is the first one used to
determine how to dereference the URI.
For example the scheme of the URI
http://weather.example.com/ is "http", and for
ftp://ftp.example.com/ it is "ftp". It is common to
classify URIs by scheme, calling the two preceding examples
respectively an "HTTP URI" and an "FTP URI".
Several URI schemes incorporate identification mechanisms that
pre-date the Web into this syntax:
- MAILTO URIs identify mailboxes:
mailto:nobody@example.org
- FTP URIs identify 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 URIs for these 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) registry [IANASchemes] maintains the mapping between
URI scheme names and their specifications. For instance, the IANA
registry indicates that the "http" scheme is defined by [RFC2616]. The process for
registration of new URI schemes is defined by RFC2717.
Since many aspects of URI processing are scheme-dependent, and
since a huge range of already deployed software is expected to be
able to process URIs, the cost of introduction of new URI schemes
is quite high.
Good practice
New URI schemes: Authors of
specifications SHOULD avoid introducing new URI schemes when
existing schemes can be used to meet the goals of the
specifications.
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
client dereferences such as 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
client to launch a particular application when retrieving a
representation, such dispatching can be accomplished at lower
expense by registering a new MIME type instead. Reasons for this
include:
- The more resource metadata is included in a URI, the more
fragile the URI becomes (e.g., sensitive to changes in
representation). Designers should choose URI schemes that allow
them to keep their options open; refer to the TAG finding
"'Deep
Linking' in the World Wide Web" for more discussion of
this topic.
- At this time, the registration process for new URI schemes is
more strict than for the registration of new media types.
Editor's note: When finding
available based on Tim Bray's discussion of this topic, link from
here.
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.
Many URI schemes include a hierarchical element for a naming
authority (the string between "//" and the next "/"), such that
governance of the name space defined by the remainder of the URI is
delegated to that authority (which may, in turn, delegate it
further). The generic syntax provides a common means for
distinguishing an authority based on a registered domain name or
server address. See section 3.2 of [URI] for more information about the authority
portion of a URI.
How authority is delegated depends on the URI scheme. The
deployment and use of different URI schemes may require varying
degrees of central coordination and administration. For example,
MAILTO, FTP, and HTTP URIs depend (in practice at least) on the use
of the DNS infrastructure; see "ICP-1: Internet Domain Name System
Structure and Delegation" [IANAICP1] for more information about how the
IANA manages delegation of domain names. For information about work
on a central registry for URNs, see "Dynamic Delegation Discovery
System (DDDS) Part Three: The Domain Name System (DNS) Database"
[RFC3403].
Successful communication between two parties about a piece of
information relies on shared understanding of the meaning of the
information. On the Web, 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 its authoritative meaning and the URIs
that refer to it. See the draft TAG finding
"Client
handling of MIME headers" for more discussion of this
topic.
In our travel scenario, the
authority over the HTTP URI
http://weather.example.com/oaxaca and the meaning of
the resource it designates is delegated to the managers of
weather.example.com.
The fragment identifier component of a URI (the string after the
"#") allows indirect identification of a secondary resource by
reference to a primary resource and additional identifying
information that is selective with respet to that resource. The
identified secondary resource may be some portion or subset of the
primary resource, some view on representations of the primary
resource, or some other resource that is merely named with respect
to the primary resource. Like the primary resource, the meaning of
the secondary resource is determined by the authority responsible
for the URI.
Although the generic URI syntax allows any URI to end with a
fragment identifier, some URI schemes do not define the semantics
of fragment identifiers. For instance, fragment identifier
semantics are not defined for MAILTO URIs.
For URI schemes that do support fragment identifiers, the
semantics of a fragment identifier are defined by the set of
representations that might result from a retrieval action on the
primary resource. The fragment's format and resolution is therefore
dependent on the media type [RFC2046] of the retrieved representation, even
though such a retrieval is only performed if the URI is
dereferenced. The presence of a fragment identifier component in a
URI does not imply that a retrieval action will take place.
Fragment identifier semantics may differ among formats. For
instance, in XHTML, fragment identifiers are specified via the
id attribute and refer to hypertext anchors. In the
Resource Description Framework [RDF10], fragments can be used to identify
anything, be it abstract (e.g., a dream) or concrete (e.g., an
automobile).
Suppose that in our travel
scenario the server returns an XHTML representation when Dan
dereferences the URI
http://weather.example.com/oaxaca. Then, by navigating
within the XHTML content, Dan finds that the URI
http://weather.example.com/oaxaca#t34 refers to
information about the temperature in Oaxaca. The resource owner has
appropriately made the meaning of the secondary resource consistent
with the meaning of the primary resource.
Interpretation of the fragment identifier during a retrieval
action is performed solely by the client; the fragment identifier
is not passed to other systems during the process of retrieval.
Thus, there are some advantages to using a URI without a fragment
identifier: only URIs work with intermediaries in the Web
architecture (e.g., proxies) or with redirection (in HTTP [RFC2616], for example).
Suppose that the managers of 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
client and the server engage in HTTP content negotiation, so that
Dan receives the best image format his client can handle. 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. This URI makes sense for the SVG
representation, since SVG defines fragment identifier semantics.
However, the URI does not make sense for the PNG and JPEG/JFIF
representations; those specifications do not define fragment
identifier semantics.
Good practice
Content negotiation with fragments:
Authors SHOULD NOT use HTTP content negotiation for different media
types that do not share the same fragment identifier semantics.
Given a URI, a system may attempt to perform a variety of
operations on the resource, as might be characterized by such words
as "denote", "access", "update", "replace", or "find attributes".
Such operations are defined by the formats and protocols that make
use of URIs. The URI specification (in [URI], section 1.2.2) defines the following terms
related to interactions through a URI.
- URI resolution
- The process of determining an access mechanism and the
appropriate parameters necessary to dereference a URI; such
resolution may require several iterations.
- URI dereference
- To dereference a URI is to use an access mechanism to perform
an action on the URI's resource.
- Resource retrieval
- A URI dereference that causes a client to retrieve a
representation of the associated resource.
During URI resolution, an agent applies in succession a finite
set of relevant specifications, 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).
Some URI schemes do not define dereference mechanisms. The URN
scheme [RFC 2141] does not
specify a dereference procedure, although [RFC 3401] describes a dereference system for
URNs.
TAG issue metadataInURI-31:
Should metadata (e.g., versioning information) be encoded in
URIs?
TAG issue siteDate-26:
Web site metadata improving on robots.txt, w3c/p3p and favicon
etc.
One of the most important actions on the Web is to retrieve a representation of a
resource (by using, for example, HTTP GET). As mentioned above, the
authority responsible for a
URI determines what the URI identifies and which
representations are used for interaction with the resource. The
representations communicate the meaning of the resource.
Good practice
Resource descriptions: Owners of
important resources SHOULD make available representations that
describe the nature and purpose of those resources.
As an example of dereferencing a URI to retrieve a
representation, suppose that
http://weather.example.com/oaxaca 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
by 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 URI specification [URI],
which states that the URI scheme (here, "http") may further
restrict the syntax and semantics of identifiers using that
scheme."
- The HTTP/1.1 protocol. Section 3.2.2 of RFC2616 [RFC2616] explains the semantics of
"http" scheme URIs. The GET method defined in HTTP/1.1 is used to
retrieve the representation of the resource.
- Once the representation has been retrieved, the media type of
the representation governs its interpretation (here, for
rendering).
Note that, in general, one cannot determine the media type(s) of
representation(s) of a resource by inspecting a URI for that
resource. For example, do not assume that a URI that ends with the
string ".html" refers to a resource that has an HTML
representation.
Dan's retrieval of weather information qualifies as a "safe"
interaction; a safe request is a read-only query or lookup. Other
Web interactions resemble orders more than queries. These "unsafe"
operations cause a change to the state of a resource. Unsafe
operations include subscription services, 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 software 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, suppose in our travel scenario that the managers of
weather.example.com offer a monthly newsletter
available by subscription. It is incorrect and
harmful to publish a page that states "By following this
link, you can subscribe to the Oaxaca Newsletter and you also
indicate that you agree to the following terms and conditions..."
This approach does not account for the fact that anyone (in
particular, a search service or a proxy) can follow this link (or
another one elsewhere with the same URI), and anyone who follows
those links may never have seen the terms and conditions.
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 draft TAG finding "URIs,
Addressability, and the use of HTTP GET and POST."
The value of a URI increases with the predictability of
interactions with 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.
- Inconsistent uses of an XML namespace URI.
- 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 the persistence of the URI. 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 persistence also improves when ambiguity is removed about
what the URI identifies. For instance, 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 (say, by ISBN), or the work itself in an abstract sense
(for example, using RDF), 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. Similarly, one should not use the same URI to refer to
a person and to that person's mailbox.
Ambiguous descriptions of what a URI identifies increase the
likelihood that two parties will think the same URI identifies
different resources, and thus that the parties will use the URI
inconsistently. This can be costly, as in the case of two databases
in which the same URI is used inconsistently; merging the two
databases might lead to confusion or errors.
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 client
that further action needs to be taken by the client 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 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].4
As we have seen, identification of a resource on the Web is
distinct from interacting with that resource. It is reasonable to
control 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
managers of weather.example.com can offer Dan and Norm
the benefits of URIs (e.g., bookmarking and linking) and still
control access to the newsletter by 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."
A representation is data that represents or
describes the state of a resource. It consists of:
- Electronic data expressed in one or more formats (e.g., XHTML,
CSS, PNG, XLink, RDF/XML, and SMIL animation) used separately or in
combination.
- Metadata about the representation, such as the Internet Media
Type (defined in RFC 2046 [RFC2046]). The Internet Media Type is the key
to the correct interpretation of a resource representation, and
governs the handling of fragment
identifiers. When transferred by a Web protocol, a representation often includes
metadata about both the representation and the message bearing the
representation (for example, some HTTP headers).
Web agents use representations to modify as well as read
resource state.
As discussed above, the owner of a resource assigns its
authoritative meaning and the URIs that refer to it. This meaning
is communicated in part through metadata that is part of the
representation, notably the Internet Media Type. At times there may
be inconsistencies between metadata and what is specified in a
format. Examples of inconsistencies between headers and format data
that have been observed on the Web include:
- The Unicode encoding of a message body (XML document) is
inconsistent with the value of the charset parameter in the message
headers.
- The namespace of the root element of a message body (XML
document) is inconsistent with the value of the content type header
in the message headers.
Clients should detect such inconsistencies but should not
resolve them without involving the user (e.g., by securing
permission or at least providing notification). Clients must not
silently ignore authoritative server metadata.
See the draft TAG finding "Client
handling of MIME headers" for more in-depth discussion
and examples.
The Web can be used to interchange resource representations in
any format. 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.
For a 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.
For a format to be widely interoperable across the Web:
- There SHOULD be a normative specification which is a stable and
widely available Web resource.
- The format specification SHOULD have an officially registered
Internet media type (see the [IANAMIME] registry). See TAG finding finding
"Internet Media
Type registration, consistency of use."
- The format specification SHOULD define the syntax and semantics
of fragment identifiers.
- The format specification SHOULD allow Web-wide linking, not
just internal document linking.
- The format specification SHOULD allow authors to use URIs
without constraining them to a limited set of URI schemes.
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.
As noted above, the utility of data formats starts with the
availability of a normative specification. Some of the desirable
characteristics of a format include:
- Attention to Programmer Needs
- A specification that is written to meet the needs of
programmers is more likely to be implemented, and thus more likely
to be useful. In particular, the specification SHOULD be in part
formal and mathematical, rather than relying exclusively on
narrative.
- Attention to Author Needs
- Formats that allow authors to intuitively and efficiently
address problems they are trying to solve, that can be readily
learned, that are simple to use, and that are interoperable are
more likely to be adopted by authors and authoring tool
developers.
- Attention to User Needs
- A number of characteristics of a format specification will
address the needs of end users, and doing so will create a market
for the format. Attention to issues of accessibility,
internationalization, and device-independence will tend to make a
format specification more flexible.
- Attention to Error-Handling
- Given that representations are generated by humans (either
coded directly or mediated by an authoring tool) and then
transmitted in a heterogeneous network, it is inevitable that
errors will occur. Specifications of data formats SHOULD be clear
about behavior in the presence of errors. It is reasonable to
specify that errors should be worked around, or should result in
the termination of a transaction or session. It is not acceptable
for the behavior in the face of errors to be left unspecified. See
the draft TAG finding "Client
handling of MIME headers" for more discussion about
error reporting.
- Issue errorHandling-20
- Information hiding
- When designing specifications that address independent
functions of a system, references between the specifications are in
general harmful. They are harmful because they 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 good for given application) to
break layers. For example, it is good for an HTTP client to be
aware of TCP speeds and round trip times to different mirror
servers in order to optimize the choice of server. When designing
specification, identify the functionalities that break layers so it
is clear when they are being used.
The section on architectural
specifications includes references to additional format
specification guidelines.
Other design issues:
This section discusses important characteristics of data formats
which can together be used to describe and understand them.
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 languages are textual. In modern textual data formats,
the characters are usually taken from the Unicode repertoire.
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 are 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 mainting 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).
All things being equal (a rare state of affairs) textual formats
are generally preferable to binary ones in Web applications.
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.
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.
In general XML-based data formats are more re-usable and
repurposable than the alternatives, although the example of XSL-FO
shows that this is not an absolute.
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,
whether the format is naturally final-form or some XML
vocabulary.
On the other hand, where such requirements are not in play,
representations that are reusable and repurposable are in general
higher in value, particularly in the case where the information's
utility may be long-lived.
Some data formats are explicitly designed to be used in
combination with others, while some are designed for standalone
use. An example of a standalone data format is PDF; it is not
typically embedded in representations encoded in other formats.
At the other extreme is SOAP, which is designed explicitly to
contain a "payload" in some non-SOAP vocabulary. Another example is
SVG, which is designed to be included in compound documents, and
which may in turn contain information encoded in other XML
vocabularies.
This characteristic is related to, but distinct from, the
final-form/reusable distinction discussed above. For example, one
can certainly imagine cases where it is useful for a representation
to include data in multiple different formats, but be considered
immutable and display-only.
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
- Versioning
- Backward compatibility
- Forward compatibility
- Optional v. mandatory extensions
- Schema restriction if designing for extensibility.
Deterministic/non-deterministic content models
More incoming from D. Orchard
Editor's note: Expect to add
reference Web
Architecture: Extensible Languages.
In many cases, the information contained in a separation 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.
More incoming from C. Lilley
The Web's vast network of hyperlinks is one of its defining
characteristics, and resource representations are thus commonly
required to contain embedded links to other resources.
This section assumes that the other resources identified by
hyperlinks are represented by URI references, a basic requirement
of Web Architecture. There are, however, many syntactic options
available for embedding such URI-based hyperlinks in resource
representations.
More incoming from N. Walsh
TAG issue: What is the scope of using XLink? xlinkScope-23.
Many resource representations are encoded in formats which are
XML vocabularies. This section discusses issues that are specific
to such data formats.
Anyone seeking guidance in this area is urged to consult the
"Guidelines For The Use of XML in IETF Protocols" [IETFXML] for the use of XML in Internet
Protocols. This document 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 the IETF BCP. 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 Web is significantly a networked information
system. Authors and applications can use URIs uniformly to identify
different resources on the Web. After representations of these
resources have been retrieved, they may be processed in a variety
of ways. Some applications (and some users) will undoubtably build
new resources by combining several representations together. This
is particularly easy, and potentially useful, when XML
representations are available for all the resources.
However, combining representations in this way moves them out of
their original context and places them in a new context. This
change of context introduces the possibility of information loss.
Any information that depended on the local context will no longer
be available.
What is needed is a mechanism for establishing a global context
for the elements and attributes in the XML resources. This problem
bears a strong resemblance to the distinction between relative and
absolute URIs. While the many hundreds of relative URI references
to "index.html" on a typical web server may be entirely unambiguous
in their respective contexts, they have no unambiguous global
meaning. But each such relative URI has an unambiguous absolute URI
that can be established in its local context and used when a
document is moved. This solves the problem for URI references.
For elements and attributes, their names can be seen as
analogous to relative URI. Within their original context, they have
meanings that are clear and entirely unambiguous. Namespaces in XML
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" [XMLNS].
Designers that use namespaces are thus providing a global
context for documents authored with their schema. Establishing this
global context allows their documents (and portions of their
documents) to be reused and combined in novel ways not yet
imagined. Failure to provide a namespace makes such reuse 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
language technologies become widely deployed, this drawback will
diminish in significance.
Namespace designers SHOULD make available human-readable
material to meet the needs of those who will use the namespace
vocabulary. The simplest way to achieve this is for the namespace
name to be an HTTP URI which may be dereferenced to access this
material. The resource identified by such a URI is called a
"namespace document."
There are many reasons why a person or agent might want more
information about the namespace. A person might want to:
- understand its purpose,
- 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,
- stylesheets, to use for presentation,
- ontologies, to use for making inferences, or
- any number of other application-specific details.
It follows that there is, in general, no single type of resource
that can be returned in response to a request for the namespace
name that will always be the most appropriate; 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
Editor's note: Where should we put a
section on mixing namespaces; is the section on processing model
more appropriate? See issue
mixedUIXMLNamespace-33.
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 context of
the media type of the representation. It follows from this that
designers of XML-based data formats SHOULD include the semantics of
fragment identifiers in their designs. The XPointer Framework [XPTRFR] provides a syntax designed
for in such fragment identifiers, and it SHOULD be used for this
purpose.
When a representation is provided whose media type is
application/xml, there are no semantics defined for
fragment identifiers, and thus they SHOULD NOT be provided for such
representations. This is also the case if the representation is
known to be XML because the media type has a suffix of
+xml as described in "XML Media Types" [RFC3023], but there is no
normative specification of fragment semantics.
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 languages
be addressed in the absence of a DTD? See draft
TAG finding "How
should the problem of identifying ID semantics in XML languages be
addressed in the absence of a DTD?".
RFC 3023 defines the media types application/xml
and text/xml, and describes a convention whereby
XML-based data formats use media types with a +xml
suffix, for example image/svg+xml.
In general, media types beginning with text/ SHOULD
NOT be used for XML representations. They create two problems:
First, intermediate agents 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.
Secondly, representations whose 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/" media types effectively precludes this good
practice.
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 document 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.