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