Another look at namespaces

[james anderson]

Andrew Layman wrote:
> 
> With all due respect to Simon St. Laurent, I believe that Tim Berners-Lee
> was correctly precise when he wrote "the document corresponding to the
> namespace URI becomes
> the place where the namespace-author can put *definitive*
> information about the intent of the namespace."  (Emphasis in the original).
> 

These remarks broadened the intent of "namespaces" to an extent where that are
no longer useful. It states and implies that they are to be used for things
for which they are, and will remain, ill suited.


The initial, cited, statement begs the question. If, as soon as one identifies
a set of names, one is required to commit to an intent, then one is not
referring to a namespace - neither in general usage nor in the specifics of
the xml-related recommendation. One is no longer concerned with an infinite
set of potential names, but with a finite set of specific names and their
associated meanings. Which is not a namespace. 

> While there are many processes that can be applied to a document, and
> correspondingly many specifications of those processes, there can be, for a
> given term in a namespace, at most one correct *definition*.
> 

This claim bears further explanation. I had, until now, understood that the
definition for a namespace was, in effect, an injection function which maps
local parts to universal names, which means the definiton for the name is the
argument to the function, but I don't think this is what "*definition*" was
intended to mean here.

> ...
> 
> As background, and to help make clear some of the thinking on this subject,
> the following is the text of a message I posted a few weeks ago to the XML
> Plenary:
> 
> ...
> 
> Further, I expect that one can argue that a namespace is an abstract concept
> denoting a set of names, and this argument is true, so far as it goes, but
> it does not go far enough:  For specific processing, to make use of a
> namespace one needs to know what names are in it, which are not, and what
> the meaning is for each name.

In the environment for which namespaces are intended, this formulation is
backwards. One needs to know which namespace a name is in, and, with respect
to a given process - or even just with respect to a given document, which
meaning is associated with that name-in-that-namespace.

The original phrasing imputes a singular, all-encompassing meaning to any
given name. This is short-sighted. It is also not what namespaces are
specified to do. The modified phrasing restricts the interpretation to
uniquely identifying an encoded entity. Which is the end which namespaces are
specified to serve.

Despite that, as my previous contributions to this list well demonstrate, I'm
certainly not the most reliable just of the recommendations authors' intent,
no matter how often i reread section 1 of the recommendation, I can't impute
an intent to encompass "what the meaning is for each name." "Allow a process
to reliably determine the meaning for a given name", yes. THose are not the
same thing.

>       Such information may be obtained by various
> means such a by reading a schema, by reading a text document, or from
> conversations with other people, but in all cases the meaning is not created
> by the processing code, the meaning informed the programmer who wrote the
> code.  For a namespace to be reliably useful, there must be a document
> defining its contents and their meaning.  A schema is, for many namespaces,
> that document.

This does not concern the reliability of the namespace, but of the schema. As
above it is more correct if reversed:  For a schema to be reliably useful, it
must define its namespaces.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)