Re: Significant W3C Confusion over Namespace Meaning and Policy

On Feb 11, 2005, at 22:17, ext Roy T. Fielding wrote:

> What does a Namespace URI identify?
> In my opinion, a namespace URI identifies a name space.  That is
> circular, of course, but the reason I say that is because there
> is a significant difference between a name space (an area in
> which names can be defined) and a name set (a set of names that
> has been defined).
> URIs are a form of name space.  They start with a scheme, which
> defines its name space by way of a scheme specification.  The
> specification may further delegate name spaces using registration
> mechanisms such as DNS.  In turn, the delegated authorities may
> further delegate their own name space via hierarchy.  For example,
> the following are all spaces for names
>    http:
> and this is by no means unique to http.  In fact, the reason we
> say that *any* URI can be used as a namespace URI is because
> what the namespace URI actually identifies is itself -- the URI.

I don't think it's necessary to say that a URI used as a
namespace name identifies anything relevant to the namespace.

I.e. whatever that URI identifies is irrelevant insofar as its
use as a namespace name is concerned.

The URI used as a namespace name is simply providing a
(presumably) globally unique string which can be paired
with a (likely) non-unique string to produce a (presumably)
globally unique term.

The function of the namespace name thus has nothing to do
with what that URI might identify or otherwise be interpreted.

I think that most of these debates about what namespaces are
or what namespace name URIs identify would go away if folks
would focus solely on the terms and not how those terms
are constructed.

In short, what we need is the analog of "URI Opacity" for qnames.

I.e, folks have to stop presuming anything about the URIs used as
namespace names, as if they identify anything relevant to either
the "namespace" or any term grounded in that namespace.

> The purpose of namespace identification is not to identify a
> particular set of names, but rather to distinguish the names
> within that space from all other similar names.  That is true
> regardless of whether we think of the namespace URI as a prefix
> for names within that space or as a { URI, name } pair.
> The URI both identifies the namespace and embodies the namespace.

I think it would be better to say that the URI used as a namespace
name delimits the namespace. But it does not function as a URI
insofar as its role as a namespace name is concerned.  Or rather,
perhaps, its interpretation as a namespace name -- such that it
identifies a namespace -- is disjunct from its interpretation as
a URI, and per that latter interpretation as a URI, it may identify
some resource entirely unrelated to the namespace.

Hence, the ability to use e.g. a mailto: URI as a namespace name.

Given {"", "foo"} the URI
<> identifies (as a URI) a mailbox,
yet the same URI (as a namespace name) identifies (or delimits)
a namespace.

IMO, the fact that these two interpretations are frequently
confused, and are ambiguous in the specs, is the main source
for this "confusion over namespace meaning".

Folks presume that because namespace names are URIs, and URIs
identify things, that what a namespace name identifies is a
namespace -- failing to understand that the interpretation of
a namespace name as a URI has no relation to its interpretation
and function as a namespace name.

> In particular, XML schemas do not define namespaces and are not
> identified by namespaces, so the effect that a new attribute may
> have on potential schemas for a document format is an indication
> that the document format *might* need to be versioned, not an
> indication that the namespace must be changed.


Agents should determine proper treatment of qnames based on
the specified DOCTYPE and not by parsing the qname and attempting
to interpret its namespace name.

Namespaces are purely a syntactic mechanism, and should not
be presumed to bear any meaning insofar as qnames are to
be interpreted.

Granted, there are issues with knowlege discovery, such as
how to discover information about a qname which is not defined
by a schema associated with the DOCTYPE (e.g. occurring in
an ANY content model) -- but there is thus an opportunity
to unify solutions to similar problems by (a) agreeing on
a standardized qname to URI mapping and (b) employing standardized
knowledge discovery solutions based on URIs (e.g. URIQA
or similar).

> If we think of the namespace as a resource, then it has state
> and that state may vary over time.  It is therefore natural to
> think of representations of that resource being the set of names
> that are defined at a specific point in time.  The same definition
> of naming and name spaces can be found within a directory for
> any modern filesystem, information service, or registry, with
> varying demands on the persistence of names within those spaces.

I would consider a namespace to be a resource (since I consider
anything that can be named to be a resource) but again, the
URI used as the namespace name does not necessarily identify
that namespace resource. It *can*. But it might not, and unless
the XML Namespaces spec is ammended to introduce such a requirement
(which I doubt would ever happen since too many namespace names
would fail to conform to such a constraint) agents should *not*
presume that the URI used as a namespace name identifies that

(not to mention that even if the URI used as a namespace name
does in fact identify the namespace, that the namespace is
not the same as a vocabulary or DOCTYPE and thus agents should
also not presume that there is any 1:1 relation between the
namespace and any vocabulary or document model, etc. etc.)

> There are good reasons for requiring that the definition of a
> name within an XML namespace must not be changed once its first
> definition has been deployed in practice.  I do not know of any
> justifiable reason why the set of names within a namespace
> cannot be extended without changing the definition of other
> names within that space, and thus without changing the
> distinctiveness of those names within their own namespace.

Agreed. Because what counts is the identity of the terms, and
the addition of new terms in the same namespace does not impact
any existing terms.

Once one gets free of the notion that namespace = vocabulary = schema,
then term management becomes a far easier matter.

The methodology I've long employed, with great success, is as

Terms are identified by URI and/or qname.

Functional vocabularies are defined which include terms which
are relevant to a particular application (and which namespace
might be used for any given term is entirely irrelevant).

Document models and/or ontologies are defined using the terms
from a particular vocabulary, or vocabularies.

Different vocabularies may share the same terms.

A given vocabulary need not include all terms known to be
defined using a given namespace.

For convenience, there is often a correlation between
key, commonly used vocabularies and namespace names, such
that all/most terms share a common namespace -- but this
is not manditory insofar as the methodology is concerned.

The URI used to identify a given vocabulary is often the
primary namespace name less the final punctuation. E.g.         identifies a vocabulary        used as a namespace name    identifies a term


{"", "term"}  identifies a term


I use major/minor versioning as follows:

The URI identifying a vocabulary will include the major
version number; and thus, most namespace name URIs also
include the major version number.

URIs identifying RDF/XML schemas relating to a given version of
a vocabulary include both major and minor numbers. E.g.  RDF/XML

Adding new terms to a vocabulary only results in an increment
of the minor version, and all such changes are presumed
backwards compatible.

Modifying the definition of a term in a way that might affect
application behavior results in an increase in the major
version of the vocabulary, and a new namespace reflecting
the new major version -- but only for those terms which
were so modified. Thus, terms which do not have modified
definitions retain their existing identity, and a given
version of a vocabulary may include terms defined with
namespace names reflecting multiple major versions. E.g.          vocabulary         namespace name    term    RDF/XML schema          vocabulary         namespace name    term    term    RDF/XML schema          vocabulary         namespace name    term    term    term    RDF/XML schema

The RDF/XML schemas would comprise definitions of
the vocabularies (e.g. using
such that

The vocabulary
includes the terms

The vocabulary
includes the terms

The vocabulary
includes the terms

(Of course, those vocabularies could also be defined
to include terms defined using other namespaces as
well, but I'm keeping these examples as simple as

Note that the term
is not the same as the term
which is not the same as
and that all three terms can be used
concurrently by different applications.

Note also that the vocabulary
went through 7 minor revisions before being
superceded by the new major version
which went through 4 minor revisions before
being superceded by the new major version
(as indicated in the major/minor numbering
  of the RDF/XML schemas)

All three major versions of the vocabulary 'FOO'
could be in use concurrently -- with different
applications employing different versions, allowing
for the vocabularies to evolve and change with
minimal impact to existing applications, and with
minimal concern about which namespace names are
used to produce identifiers for terms.

What counts are the definitions of the functional
vocabularies and the definitions of the terms, not the
lexical properties of the terms' identifiers.

With this methodology, namespaces are syntactic, and
any consistency or regularity in namespace usage is
based solely on convenience (no different than using
mnemmonic identifiers rather than cryptic ones) yet
there is no fundamental non-syntactic significance to
any particular namespace name anywhere.

C.f. for real usage examples
of this methodology...




Patrick Stickler
Nokia, Tampere

Received on Tuesday, 15 February 2005 09:34:10 UTC