Re: Namespaces and namespace names: a new synthesis?

> Maybe the problem we got into was because all of the W3C recommendations
> use http URLs to identify resources that aren't really served by http
> servers.

No, the problem is that some people don't like the fact that the
namespace spec uses URIs to name namespaces and are trying to
incompatibly change the specification and break two years worth
of XML development in the process.

Whether or not a namespace is a resource is an interesting
philosophical discussion. Probably given the vagueness of the
definition of Resource in the RFC it is impossible to find anything
that isn't a resource, so I'm prepared to accept that namespaces
are. However whether or not a namespace is a resource, it is not
(usually, or necessarily) the resource identified by the URI
which is used as the namespace name.

Machines at NAG are named after english towns, andover, hereford, ...
The machines are not towns, its just that towns supply a ready
collection of names. machines don't suddenly acquire town-like
properties just because they have town names.

That is how namespace names are allocated. To name a namespace (and
that's the only thing you can do with a namespace as such, a name
being its only property) you just pick a URI of some resource
over which you have control. That resource is absolutely _not_
forced to be the namespace, you just use the URI mechanism
to get yourself a name that no one else will use as a namesapace
name.

That is why John's proposal was interesting: it clearly separates
the URI that identifies the namespace-as-a-resource from the
property of that namespace, namely its name (which coincidentally
is also a URI). One can argue the details, whether data: is the best
scheme or whether a different (or new) scheme would have better
properties but that is a detail that could be worked on if the general
principle was accepted.

So the resource identified by mailto:david@dcarlisle.demon.co.uk
has certain properties (I am not quite sure what this resource is,
whether it is "my incoming mail" or "my mailbox at demon's server"
or whatever. But whatever the resource identified by that resource is
it is in no way changed if I decide to do this:
<x xmlns="mailto:david@dcarlisle.demon.co.uk"/>
and put an element with local name x into a namespace named after
my mail URI. And using your mail URI, or you company home page URI
or any other such URI that you `own'  or have the right to create,
such as xmlns="http://www.dcarlisle.demon.co.uk/no-file-here-yet"
is absolutely correct and intended usage of namespaces.
It may be polite to beginners to stick an html page at that URI
if nothing else is there that says this URI is used as a namespace
name, perhaps you wanted the spec or the dtd or... this is
what the W3C did for their namespaces until the recent unfortunate
decision to put a schema directly at the xml namespace URI.

Technically I believe that this mechanism of allocating names via the
URI system is consistent and can be made to work, and that it is way
to late to change it.

I don't actually _like_ it. I used not to like it because it leads to
namespace names that look like they perhaps ought to be dereferenced.
Which leads to understandable initial beginner questions like
"what do I put at the namespace URI"
or
"How do I parse a document using namesaces if I am not connected"
etc

However experience has shown these beginner questions can be handled
and people do fairly easily get the basic idea that a namespace name
is just a name.

However now it turns out that "beginner questions" was not the main
thing wrong with using URIs as namespace names, the main problem
is that it was more or less inevitable that at some point (like now)
someone would try to suggest changing the semantics so that the
resource identified by the namespace name actually _was_ the
namespace. There can be no justification in changing the semantics
of namespace names at this point. As I said at the beginning 
of this list the detailed point about what to do with relative 
URI is really minor compared with this major point of principle that
you can't issue recommendations, let people build systems using that,
then on a whim just decide to revoke the recommendation and do
something else.

It is clear that something more like java package names or FPI
would have avoided many of these issues but there were problems with
each of these: java names require you to have a domain registered
whereas URIs were (so we were told on xml-dev) intentionally picked as
an enabling mechanism, anyone with a free ISP email address can make
themselves a namespace name.  FPI would be good except getting an offically
registed FPI is in practice impossible. So the decision was taken to
use URI references as namespace names, obviously other decisions could
have been taken, other naming schemes could have been used, but that
is history.

David

Received on Saturday, 27 May 2000 06:27:37 UTC