Copyright © 2002-2003 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark , document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
The World Wide Web is an information system that relates information sources and services through the use of hypertext-style relationships, creating in which a web network of information that spans the Internet. Architecture resources are related through hypertext links. Web architecture defines the desired operational behavior of components agents within this information system, including software, machine, and human components, system and deleted text: protocols for protocols that govern interactions between components. The Web architecture these agents. It is influenced by social requirements and software engineering principles, leading to design choices that constrain the behavior of the Web in order for the system to achieve desired properties: to be an efficient, scalable, shared information space that will can continue to grow indefinitely across languages, cultures, and information mediums. media. This document is organized to reflect the three dimensions of Web architecture: identification, interaction, and representation.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The A list of current W3C publications and the latest status revision of this document series is maintained at technical report can be found in the W3C. W3C technical reports index at http://www.w3.org/TR/.
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 The primary changes in this draft contains substantial revisions based on discussion concern TAG comments made at the TAG's 21-23 July face-to-face meeting in Vancouver. 4 Aug 2003 teleconference , review comments from Tim Bray, and revised text from Norm Walsh for section 4. 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. deleted text: 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.
Highlighted entries in this table of contents link to principles, constraints, good practice notes, and design choices emphasized in the document.
The World Wide Web ( <acronym> WWW </acronym>, or simply Web) is an information system that relates information sources following principles and services, referred to collectively as <a name="def-resource" id="def-resource"> <dfn> resources </dfn> </a>, through the use of hypertext-style relationships, creating a web of information that spans the Internet. The Web's primary goal is to create good practice notes explained in this document are listed here for convenience.
Identification and maintain an efficient, scalable, shared information space that will continue to grow indefinitely across languages, cultures, Resources | Interaction | Representations and information mediums. </p> <p> A simple <a shape="rect" name="scenario" id="scenario"> travel scenario Formats |
---|---|---|
|
|
|
The World Wide Web ( WWW , or simply Web) is an information system in which the information objects, referred to collectively as resources , related through hypertext links.
A travel scenario is used throughout this document to illustrate some typical behavior of Web agents -- software acting in this system on behalf of a person, entity, or process. Agents include servers, proxies, browsers, spiders, multimedia players, and other user agents (software acting on behalf of a person).
While
planning
a
trip
to
Mexico,
Nadia
reads
"Oaxaca
weather
information:
'
http://weather.example.com/oaxaca
'"
in
a
glossy
travel
magazine.
Nadia
has
enough
experience
with
the
Web
to
recognize
that
"
http://weather.example.com/oaxaca
"
is
a
URI.
Given
the
context
in
which
the
URI
appears,
she
can
expect
that
it
should
allow
her
to
access
relevant
weather
information.
When
Nadia
enters
the
URI
into
her
browser:
This scenario (elaborated on throughout the document, and identified by the book icon) illustrates the three architectural divisions of the Web that are discussed in this document:
http://weather.example.com/oaxaca
".
The final rendered result of these interactions, referred to as a <a name="def-webpage" id="def-webpage"> <dfn> Web page </dfn> </a>, is defined by following illustration shows the application steady-state simplest relationship between the last interaction identifier, resource, and the next user request. </li> </ol> representation.
deleted text: Architecture defines the desired operational behavior of components within the system, including software, machine, and human components, and protocols for interactions between components. The Web architecture is influenced by social requirements and software engineering principles, leading to design choices that constrain the behavior of the Web in order for the system to achieve desired properties. This document is an ongoing attempt to describe the properties we desire of the Web and the design choices that have been made to achieve them.
This document promotes re-use of existing standards when suitable, and gives some guidance on how to innovate in a manner consistent with the Web architecture.
The intended audience for this document includes:
The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in accordance with RFC 2119 [ RFC2119 ].
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.
deleted text: <p> We assume readers are familiar with the rationale for some of the general design principles: minimal constraints (fewer rules make the system more flexible), modularity, minimum redundancy, extensibility, simplicity, and robustness. </p>This document focuses on the architecture of the Web. Other groups inside and outside W3C also document principles related to address specialized aspects of Web architecture, including accessibility, internationalization, device independence, and Web Services. The section on Architectural Specifications includes some references.
This document is designed attempts to balance the value of brevity and precision with the value of illustrative examples. TAG findings provide more background, motivation, and examples.
The architecture described in this document is primarily 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 ].
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. will agree upon a shared set of identifiers with agreed to and on their meanings. This shared vocabulary has a tangible value: it reduces the cost of communication. The ability to use common identifiers across communities 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 agents 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 agent is case-insensitive) to reduce the risk of false negatives and positives. Please refer to section 6.3 6.1 of [ URI ] for more information about reducing the risk of false positives and negatives.
Web components agents 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
agents
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,
Thus,
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
agents
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
agents
convey
information
about
a
resource.
deleted text: The more resource metadata is included in a URI, the more fragile the URI becomes (e.g., sensitive to changes in representation). </p> <p> Editor's note : deleted text: When finding available on URI opacity, link from here. See TAG issue metadataInURI-31 and TAG finding The use of Metadata in URIs . 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 siteData-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
Each
URI
scheme
specification,
which
has
a
normative
specification
that
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
whether
and
how
a
component
an
agent
can
dereference
the
URI
.
Several URI schemes incorporate information systems that pre-date the Web into the URI syntax:
mailto:nobody@example.org
ftp://example.org/aDirectory/aFile
news:comp.infosystems.www
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://www.example.org/something?with=arg1;and=arg2
ldap://ldap.itd.umich.edu/c=GB?objectClass?one
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
agent
dereferences
such
a
URI,
if
what
really
happens
is
that
HTTP
GET
is
invoked
to
retrieve
an
HTML
representation
of
the
resource,
then
an
"http"
URI
would
have
sufficed.
If
a
URI
scheme
exists
that
meets
the
needs
of
an
application,
designers
should
use
it
rather
than
invent
one.
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 agent to launch a particular application when retrieving a representation, such dispatching can be accomplished at lower expense by registering a new Internet Media Type instead.
The use of unregistered URI schemes is discouraged for a number of reasons:
When
navigating
within
the
XHTML
data
that
Dan
Nadia
receives
as
a
representation
of
the
resource
identified
by
"
http://weather.example.com/oaxaca
",
Dan
Nadia
finds
that
the
URI
"
http://weather.example.com/oaxaca#tom
"
refers
to
information
about
tomorrow's
weather
in
Oaxaca.
This
URI
includes
the
fragment
identifier
"tom"
(the
string
after
the
"#").
The fragment identifier component agent of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. deleted text: 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:
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.
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 agent 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 deleted text: 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
provides
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
Nadia's
browser
and
the
server
engage
in
HTTP
content
negotiation,
so
that
Dan
Nadia
receives
the
best
image
format
his
her
browser
can
handle
or
the
image
format
he
she
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
Nadia
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 an agent 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: Available representations: 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
A
succession
of
specifications
applied
is:
agents
carries
out
the
retrieval
by
implementing
the
following
relevant
specifications:
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."
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."
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 Nadia's retrieval of weather information qualifies as a "safe" interaction; a safe interaction is one where the deleted text: 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 subscribing to a newsletter, posting to a list, or modifying a database.
Safe interactions are important because these are interactions where users can browse with confidence and where software programs agents (e.g., search engines and browsers that pre-cache data for the user) can follow links safely. Users (or components agents acting on their behalf) do not commit themselves to anything by querying a resource or following a link.
Principle
Safe retrieval: Components Agents 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:
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 URIs. The choice of a constraint imposed by technological means. particular URI scheme provides no guarantee that those URIs will be persistent, nor that they will not be persistent.
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, Example, 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 to identify 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,"
Ambiguity,
an
error,
should
not
be
confused
with
indirect
identification,
which
is
common.
One
indirectly
identifies
things
though
related
things,
such
as
people
by
their
mailboxes,
and
organizations
by
their
Web
pages.
For
example,
one
may
identify
when
conference
organizers
ask
meeting
participants
to
register
by
using
giving
their
email
addresses
(e.g.,
"
<code>
joe@example.com
</code>
").
In
this
case,
all
addreses,
both
parties
know
that
they
are
using
a
the
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
"
The
statement
"'
http://www.example.com/moby
"
'
identifies
"Moby
Dick"
can
lead
to
confusion
because
this
might
be
interpreted
as
any
one
'Moby
Dick'"
is
a
source
of
ambiguity
since
one
could
understand
the
following
statement
to
refer
to
very
distinct
resources:
a
particular
printing
of
this
work,
or
the
work
itself
in
an
abstract
sense,
or
the
fictional
white
whale,
or
a
particular
copy
of
the
book
on
the
shelves
of
a
library
(via
the
Web
interface
of
the
library's
online
catalog),
or
the
record
in
the
library's
electronic
catalog
which
contains
the
metadata
about
the
work,
or
the
Gutenberg
project's
online
version
.
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 Nadia and Norm Dirk both subscribe to the "weather.example.com" newsletter. Dan Nadia wishes to point out an article of particular interest to Norm, Dirk, using a URI. The authority responsible for "weather.example.com" can offer Dan Nadia and Norm Dirk the benefits of URIs (e.g., book marking and linking) and still limit access to the newsletter to authorized parties. The Web provides several mechanisms to control access to resources, 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.
The integration One area of internationalized work involves the creation of globally unique identifiers (i.e., composed in a file-sharing system without centralized or hierarchical administration.
Web agents exchange information via messages that are constructed according to a non-exclusive set of characters beyond those allowed by [ <a shape="rect" href="#URI"> URI messaging protocols (e.g., HTTP, FTP, NNTP, SMTP 10 ]) into the , etc.). A message exchanged between Web architecture agents is an important octet sequence consisting of representation data and open issue. See TAG issue <a shape="rect" href="http://www.w3.org/2001/tag/ilist#IRIEverywhere-27"> IRIEverywhere-27 possibly three types of metadata:
Emerging Semantic Web technologies, including "DAML+OIL" [ <a shape="rect" href="#DAMLOIL"> DAMLOIL </a> ] This section will describe the architectural principles and "Web Ontology Language (OWL)" [ <a shape="rect" href="#OWL10"> OWL10 </a> ], define RDF properties constraints regarding interactions between agents, including such topics as <code> equivalentTo </code> network protocols and <code> FunctionalProperty </code> to state -- or at least claim -- formally that two URIs identify interaction styles, along with interactions between the same resource. </p> </div> <div class="section"> <h4> 2.8.3. <a id="dynamic-delegation" shape="rect" name="dynamic-delegation"> Work on dynamic authority delegation </a> </h4> <p> The Dynamic Delegation Discovery System ( <acronym> DDDS </acronym> ) ([ <a shape="rect" href="#RFC3401"> RFC3401 </a> ] Web as a system and related RFCs) is used to implement lazy binding the people that make use of strings to data, in order to support dynamically configured delegation systems. it. This system is designed to allow resolution of any type of URI, in particular URNs. </p> </div> <div class="section"> <h4> 2.8.4. <a id="non-hier-admin" shape="rect" name="non-hier-admin"> Non-hierarchical administration </a> </h4> <p> One area will include the role of work involves architectural styles, such as REST and SOAP, and the creation impact of globally unique identifiers in a file-sharing system without centralized or hierarchical administration. meta-architectures, such as Web Services and the Semantic Web.
deleted text: </div> </div> </div>
In
the
travel
scenario
,
Dan
Nadia
retrieves
a
representation
from
the
weather
site
"
http://weather.example.com/oaxaca
".
He
She
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
Nadia'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 to the message. HTTP protocol. The remainder message consists of the several headers and deleted text: the message body together comprise a <a shape="rect" href="#representation"> representation </a> JPEG image. Some of the resource identified by " <code> http://example.com/satimage/oaxaca </code> ". headers (e.g., 'Transfer-encoding') comprise the message metadata.
The
browser
reads
the
headers,
learns
from
the
'Content-Type'
field
that
the
Internet
Media
Type
of
the
representation
data
is
"text/jpeg",
text/jpeg
,
reads
the
sequence
of
octets
that
comprises
the
representation
data,
and
renders
the
image.
Dan Nadia decides to book a vacation to Oaxaca at "booking.example.com." He She completes a series of HTML forms and is ultimately asked for credit card information to purchase the airline tickets. He She provides this information in another HTML form. When he she presses the "Purchase" button, his her browser opens another network connection to the server at "booking.example.com" and sends a message conforming to the rules for an HTTP POST request. As described by the HTML specification, the message data consists of a set of name/value pairs corresponding to the HTML form fields. Note that this is not a <a shape="rect" href="#safe-interaction"> safe interaction </a> since Dan wishes to change the state of the system by exchanging money for airline tickets. </p> <p> 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. </p> <div class="section"> <h3> 3.1. <a shape="rect" name="messages" id="messages"> Messages </a> </h3> <p> Web components exchange information via messages that are constructed according to a non-exclusive set of messaging protocols (e.g., HTTP, FTP, NNTP, SMTP <sup> <a name="note10" id="note10" href="#smtp1"> 10 </a> </sup>, etc.). A <a name="def-message" id="def-message"> <dfn> message </dfn> </a> exchanged between Web components is an octet sequence consisting of: </p> <ol> <li> <a name="message-data" id="message-data"> <dfn> Message data </dfn> </a>: Electronic data such as a <a shape="rect" href="#representation"> resource representation </a>. </li> <li> <a name="message-metadata" id="message-metadata"> <dfn> Message metadata </dfn> </a>: 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 HTML specification, the deleted text: request method. A message may even include "meta-metadata" (for message-integrity checks). </li> </ol> <p> This section will describe data consists of a set of name/value pairs corresponding to the architectural principles and constraints regarding interactions between components, including such topics as network protocols and HTML form fields. Note that this is not a safe interaction styles, along with interactions between since Nadia wishes to change the state of the deleted text: Web as a system by exchanging money for airline tickets.
The server reads the POST request, and after performing the people booking transaction returns a message to Nadia's browser that make use contains a representation of deleted text: it. This will include the role results of architectural styles, such as REST and SOAP, and Nadia's request. The representation data is in HTML so that it can be saved or printed out for Nadia's records. Note that neither the impact of meta-architectures, such as Web Services and data transmitted with the Semantic Web. POST nor the data received in the response necessarily correspond to any resource named by a URI.
Good practice
The representation of the state of a resource is an octet sequence consisting of:
Web components agents 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 using 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 Nadia receives depends on a number of factors, including:
http://weather.example.com/oaxaca
";
Inconsistencies between the format of representation data and assigned representation metadata do occur. Examples that have been observed in practice include:
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 Nadia's browser detects a problem, Dan's Nadia's browser must not silently ignore the problem and render the GIF image. Dan's Nadia's browser can notify Dan Nadia of the problem, notify Dan Nadia and take corrective action, etc. Of course, user agent designers should not ignore usability issues when handling this type of error; notification may be discreet, and handling may be tuned to meet the user's preferences.
See the TAG finding " Client handling of MIME headers" for more in-depth discussion and examples.
Furthermore, server managers 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 agents able to handle them) can be are 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 agent behavior in the face of error conditions.
See the TAG finding " Client handling of MIME headers" for more discussion about error reporting. See also TAG issue errorHandling-20 .
When designing specifications that address independent functions of a system, references between the specifications are are, in general 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 agent 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 deleted text: 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. </p> <p> In principle, all data can be represented using textual formats. </p> <p> 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. </p> <p> 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. </p> <p> 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). </p> <p> It is important to emphasize that intuition as to such matters as of data size so represented include numeric values, pointers, and processing speed are not a reliable guide in compressed data deleted text: format design; quantitative studies are essential to a correct understanding of the trade-offs. </p> <p> TAG issue <a shape="rect" href="http://www.w3.org/2001/tag/ilist#binaryXML-30"> binaryXML-30 </a>: Effect of Mobile on architecture - size, complexity, memory constraints. Binary infosets, storage efficiency. all sorts.
deleted text: </div> <div class="section"> <h3> 4.6. <a shape="rect" name="composition" id="composition"> Composition of Data Formats </a> </h3>Many modern In principle, all data format specifications include mechanisms for composition. These mechanisms range from relatively shallow and limited to relatively deep and sophisticated. can be represented using textual formats.
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 The trade-offs between binary and textual data formats are embedded complex and application-dependent. Binary formats can be substantially more compact, particularly for complex pointer-rich data structures. Also, they can be consumed more rapidly by agents in the containing data, those cases where they have can be loaded into memory and used with little or no effect on the content of the image. conversion.
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, Textual formats are often more portable and descendents is not always obvious. </p> <p> Near the middle of the spectrum, interoperable, since there are container formats such as SOAP which fully expect to be composed from multiple namespaces but which provide an overall semantic relationship fewer choices for representation of message envelope the basic units (characters), and payload. those choices are well-understood and widely implemented.
These relationships Textual formats also have the considerable advantage that they can be mixed directly read and nested arbitrarily. In principle, a SOAP message understood by human beings. This can contain a JPEG image that contains an RDF comment that references a vocabulary simplify the tasks of terms for describing creating and maintaining processing software, and allow the image. </p> <p> Composition is related direct intervention of humans in the processing chain without recourse to but distinct from tools any more complex than the question ubiquitous text editor. Finally, it simplifies the necessary human task of whether a learning about new data format formats (the "View Source" effect).
It is intended important to emphasize that intuition as a <a shape="rect" href="#final-form"> final form </a>. For example, one can imagine embedding SVG in a JPEG image thus combining final-form to such matters as data size and reusable components, whereas a SOAP envelope might provide nothing more than a container for processing speed are not a particular payload that has no presentation form at all. </p> <p> TAG issue <a shape="rect" href="http://www.w3.org/2001/tag/ilist#xmlProfiles-29"> xmlProfiles-29 </a>: When, whither and how to profile W3C specifications reliable guide in data format design; quantitative studies are essential to a correct understanding of the XML Family? </p> <p> TAG issue <a shape="rect" href="http://www.w3.org/2001/tag/ilist#mixedUIXMLNamespace-33"> mixedUIXMLNamespace-33 </a>: Composability for user interface-oriented XML namespaces </p> <p> TAG issue <a shape="rect" href="http://www.w3.org/2001/tag/ilist#xmlFunctions-34"> xmlFunctions-34 </a>: XML Transformation and composability (e.g., XSLT, XInclude, Encryption) trade-offs.
TAG issue <a shape="rect" href="http://www.w3.org/2001/tag/ilist#RDFinXHTML-35"> RDFinXHTML-35 binaryXML-30 : Syntax and semantics for embedding RDF in XHTML Effect of Mobile on architecture - size, complexity, memory constraints. Binary Infosets, storage efficiency.
Editor's note : The TAG has begun work on a finding on the topic of extensibility and versioning. The text in this section is likely to change once that finding has been published.
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:
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 agents 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
<p class="practice"> <a shape="rect" name="compatibility-behavior" id="compatibility-behavior"> Compatibility behavior: </a> Format designers SHOULD define expected behavior when components designedCompatibility behavior: Format designers SHOULD define expected behavior when agents 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 ].
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 process one version 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 format encounter SOAP message can contain a compatible version JPEG image that contains an RDF comment that references a vocabulary of terms for describing the format. image.
In some cases, format designers require that new features be supported (i.e., not ignored). In this case, Composition is related to but distinct from the new version question of the whether a data format deleted text: (N) may be backwards compatible with the earlier version (M), but M is not forwards compatible with N. The intended as a final form . For example, one can imagine embedding SVG in a JPEG image thus combining final-form and reusable agents, whereas a SOAP 1.2 Recommendation [ <a shape="rect" href="#SOAP12"> SOAP12 </a> ], envelope might provide nothing more than a container for example, defines the <code> mustUnderstand </code> attribute a particular payload that has no presentation form at all.
TAG issue xmlProfiles-29 : When, whither and how to profile W3C specifications in <a shape="rect" href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapmu"> section 5.2.3 </a>. 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)
For more information on format extensibility, refer to "Web Architecture: Extensible Languages" [ <a shape="rect" href="#EXTLANG"> EXTLANG </a> ]. TAG issue RDFinXHTML-35 : Syntax and semantics for embedding RDF in XHTML
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
hyperlink
references
(hyperlinks).
to
other
resources,
via
URIs.
The
simplicity
of
<a
href="#foo">
as
a
link
to
foo
and
<a
name="foo">
as
the
anchor
foo
are
partly
(perhaps
largely)
responsible
for
the
birth
of
the
hypertext
Web
as
we
know
it
today.
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) agents) that have no control or write access to the other end point.
deleted text: <p> 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. </p> <p> All of the current common linking mechanisms identify resources by URI reference. </p>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
Good practice
Web linking: Format specification designers SHOULD provide mechanisms that allow Web-wide linking, not just internal document linking.
deleted text: <p> 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. </p> <p> TAG issue: What is the scope of using XLink? <a shape="rect" href="http://www.w3.org/2001/tag/ilist#xlinkScope-23"> xlinkScope-23 </a>. </p> <p> 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. </p>Good practice
URI genericity: Format specification designers SHOULD allow authors to use URIs without constraining them to a limited set of URI schemes. </p> <p class="prefix"> Good practice </p> <p class="practice"> <a shape="rect" name="qname-caution" id="qname-caution"> QName caution: </a> 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. schemes.
See also the TAG finding <cite> " <a shape="rect" href="http://www.w3.org/2001/tag/doc/qnameids.html"> Using QNames as Identifiers section on hyperlinks in Content </a> " </cite> for more information. See also TAG issues <a shape="rect" href="http://www.w3.org/2001/tag/ilist"> rdfmsQnameUriMapping-6 </a> and <a shape="rect" href="http://www.w3.org/2001/tag/ilist#qnameAsId-18"> qnameAsId-18 XML .
Many representations are encoded using contain data formats based on which is XML-based , that is to say conforms to the syntax rules defined in the XML 1.0 specification [XML10] . This section discusses issues that are specific to such formats. Anyone seeking guidance in this area is urged to consult the "Guidelines For The 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:
The authority responsible for "weather.example.com" realize realizes that they it can provide more interesting representations by creating instances that consist of elements defined in different published XML-based formats, 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 "expanded name" of an XML element or attribute name is the combination of its namespace URI and its local name. This is represented lexically in documents by associating namespace names with (optional) prefixes and combining prefixes and local names with a colon as described in "Namespaces in XML."
Format specification designers that declare namespaces thus provide a global context for instances of the data format. Establishing this global context allows those instances (and portions thereof) to be re-used and combined in novel ways not yet imagined. Failure to provide a namespace makes such re-use more difficult, perhaps impractical in some cases.
Good practice
Use Namespaces: Format specifications that create new XML vocabularies SHOULD place all element names and global attribute names in a namespace.
Attributes are always scoped by the element on which they appear. In that respect they are a somewhat special case. An attribute that is "global," that is, one that might meaningfully appear on a great many elements, including elements in other namespaces, should be explicitly placed in a namespace. Local attributes, ones associated with only a particular element, need not be namespaced since their meaning will always be clear from the context provided by that element.
The
type
attribute
from
W3C
XML
Schema
is
an
example
of
a
global
attribute.
It
can
be
used
by
authors
of
any
vocabulary
to
make
an
assertion
about
the
type
of
the
element
on
which
it
appears.
The
type
attribute
occurs
in
the
W3C
XML
Schema
namespace
and
must
always
be
fully
qualified.
The
frame
attribute
on
an
HTML
table
is
an
example
of
a
local
attribute.
There
is
no
value
in
placing
that
attribute
in
a
namespace
since
the
attribute
is
very
unlikely
to
be
useful
on
an
element
other
than
an
HTML
table.
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.
More sophisticated linking mechanisms have been invented for XML formats. XPointer allows links to address content that does not have an explicit, named anchor. XLink allows links to have multiple ends and to be expressed either inline or in "link bases" stored external to any or all of the resources identified by the links it contains.
For formats based on XML, format designers should 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
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 .
Dan Nadia receives a representation from "weather.example.com" in an unfamiliar data format. He She knows enough about XML to recognize which XML namespace the elements belong to. Since the namespace is identified by a URI, he she asks his her browser to retrieve a representation of the namespace via that URI. He She gets back some useful data that allows him her to learn more about the data format; this is called a namespace document . Dan's Nadia's browser may also be able to use deleted text: machine-readable data optimized for machines 12 automatically to perform useful tasks on Dan's Nadia's behalf, such as download additional software components agents to process and render the format.
There are many reasons why a person or other component agent might want more information about the namespace. A person might want to:
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:
Good practice
Namespace documents: XML namespace designers SHOULD make available human-readable material intended for people to read and deleted text: machine-readable material optimized for machines in order 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,
13
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
Many
people
assume
that
deleted text:
when
an
element
has
an
attribute
that
is
declared
in
a
DTD
to
be
of
type
ID,
then
the
fragment
identifier
#abc
</code>
,
when
refering
to
XML
data,
identifies
the
element
which
has
an
attribute
of
that
type
whose
value
is
<code>
"abc"
</code>.
in
the
document
with
the
ID
"abc".
However,
there
is
no
normative
support
for
this
assumption
and
it
is
problematic
in
practice.
Unfortunately,
there
are
a
number
of
open
issues
associated
with
finding
the
element
with
the
ID
"abc"
in
an
XML
document.
In
XML,
the
quality
of
"being
an
ID"
is
associated
with
the
type
of
the
attribute,
not
it's
name.
Consider
the
following
fragment:
<section
name="foo">
.
Does
the
section
element
have
the
ID
"foo"?
One
cannot
answer
this
question
by
examining
the
element
and
its
attributes
alone.
Finding
the
IDs
in
a
document
requires
additional
processing.
xs:ID
.
To further complicate matters, DTDs establish the ID type in the Infoset whereas W3C XML Schema produces a PSVI but does not modify the original Infoset. This leaves open the possibility that a processor might only defined way look in the Infoset and consequently would fail to establish that an attribute recognize schema-assigned IDs.
Editor's
note
:
W3C's
XML
Core
Working
Group
is
of
type
investigating
a
solution
that
could
provide
ID
is
via
values
in
well-formed
documents
that
have
no
associated
schema
through
a
DTD,
which
may
not
exist
or
may
not
be
available.
reserved
attribute,
xml:id
.
TAG issue fragmentInXML-28 : Do fragment identifiers refer to a syntactic element (at least for XML content), or can they refer to abstractions? deleted text: 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
.
These
Internet
Media
Types
create
two
problems:
First,
intermediaries
in
the
for
data
identified
as
text/*
Web
intermediaries
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.
false
and
will
cause
the
document
to
be
not
well-formed.
Second,
representations
whose
Internet
Media
Types
begin
with
text/
are
required,
unless
the
charset
parameter
is
specified,
to
be
considered
to
be
encoded
in
US-ASCII.
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.
Good practice
XML
and
text/*
:
In
general,
Internet
Media
Types
beginning
with
text/
SHOULD
NOT
be
assigned
to
XML
representations.
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 the utility of information is useful. meant for people to read as well as information optimized for machines.
Glossary not yet completed .
Editor's note : The TAG is still experimenting with the categorization of points in this document. This list is likely to change. It has also been suggested that the categories clearly indicate their primary audience.
The important points of this document are categorized as follows:
*
had
been
chosen
instead,
the
large-scale
result
would,
most
likely,
have
been
the
same.
Other
design
choices
are
more
fundamental;
these
are
the
focus
of
this
document.
Editor's note : The usage of a normative reference in this document needs clarification.
This document was authored by the W3C Technical Architecture Group which included the following participants: Tim Berners-Lee (co-Chair, W3C), Tim Bray (Antarctica Systems), Dan Connolly (W3C), Paul Cotton (Microsoft Corporation), Roy Fielding (Day Software), Chris Lilley (W3C), David Orchard (BEA Systems), Norman Walsh (Sun), and Stuart Williams (co-Chair, Hewlett-Packard).
The TAG thanks people for their thoughtful contributions on the TAG's public mailing list, www-tag ( archive ).