1 Preface
Namespaces are a mechanism for managing names in a distributed way that
greatly reduces the likelihood that two independent parties will create
the same name for different purposes.
An XML namespace has a namespace name (a URI) and a set of local names
(NCNames as
defined in [XML Namespaces]). Using a URI leverages the
well-understood URI
allocation mechanisms of [WebArch Vol 1].
[XML Namespaces] defines a syntactic shorthand for the combination
of a namespace name and a local name: the qualified name, or “QName”.
(Note that languages which use QNames as identifiers
are required
to provide a mapping from QNames to URIs.)
The proposal to define a new local name, “id”, in
the namespace “http://www.w3.org/XML/1998/namespace” (the
xml: namespace) raised a question about the identity
of a namespace. Concretely, it exposed two perspectives:
One perspective was that the
xml: namespace consisted of xml:space,
xml:lang, and xml:base (and no other names)
because there was a point in time in which those where the only three
names from that namespace that had a defined meaning.
The other
perspective was that the xml: namespace consisted of all
possible local names and that only a finite (but flexible) number of
them are defined at any given point in time.
Colloquially, we often speak of “adding a name” to a namespace.
Here we prefer to speak of “defining a name” or otherwise licensing
the interpretation of a name. For example, the [xml:id]
specification defines the meaning of the local name “id” in the
xml: namespace. Similarly, a namespace created to hold
the names of all the reserved words in a programming language would
license the interpretation of those QNames without explicitly defining
each of them.
2 Namespace Definitions
The publication of [xml:id] as a
Recommendation,
provided a partial answer to the question of which perspective is
correct. Adding a definition for the local name “id” in the
xml: namespace demonstrated that the number of local names
defined in the xml: namespace could be extended.
The question remains, however, as to whether the other position is
ever sound. This Finding takes the position that it is.
Namespaces, originally designed to provide names for XML elements
and attributes, have been adopted much more broadly by the web
community. They are now used not simply for elements and attributes
but for function names, tokens, and identifiers for ever more
purposes.
The xml: namespace demonstrates that some namespaces
benefit from a policy that allows additional names to be defined in them
over time. This does not preclude the possibility that some
namespaces would benefit from a policy that forbids such extension.
From these observations, we conclude that the following good practice
applies:
Good Practice
Specifications that define namespaces
SHOULD explicitly state their policy with respect
to changes in the names defined in that namespace.
For namespaces that are not immutable, the specification
SHOULD describe how names may be given definitions
(or have them removed) and by whom.
If a namespace document is provided, as
[WebArch Vol 1] recommends, the namespace change policy
SHOULD be stated in the namespace document.
As a general rule, resources on the web can and do change. In the
absence of an explicit statement, one cannot infer that a namespace
is immutable.
3 References
- RFC 2119
- S.
Bradner. Key words for use in RFCs to Indicate Requirement Levels.
IETF. March, 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
- XML Namespaces
- Tim Bray, Dave Hollander, Andrew Layman, editors.
Namespaces in XML.
World Wide Web Consortium, 1999. (See http://www.w3.org/TR/REC-xml-names/.)
- WebArch Vol 1
- Ian Jacobs and Norman Walsh, editors.
Architecture of the World Wide Web, Volume 1.
World Wide Web Consortium, 2004.
(See http://www.w3.org/TR/webarch/.)
- xml:id
- Jonathan Marsh, Daniel Veillard, and Norman Walsh, editors.
xml:id Version 1.0.
World Wide Web Consortium, 2005.
(See http://www.w3.org/TR/xml-id/.)