xml-dev - Re: simple question on namespaces.

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

Paul T. sometimes has a pretty annoying way of pursuing debate (which
I enjoy, since I do as well, and I love the smell of strife).  The way
he introduced this one was no exception.  Paul is a brilliant and
very practical developer and demonstrates significant real-life XML
experience, even in the context of  this list.  Annoying his style might
be, but I never fail to learn something from him in a given thread.

Seeing that he asked the namespace question in newbie fashion, I knew
something was up.  Paul was as usual dropping incendiary bombs in
innocent-looking, pink, fuzzy packages. Of course he soon got to the heart
of the matter, but I've noticed that everyone else still seems to be
waving him off off-handedly.

I think his questions are *very* important, and that the answers from even
such as Tim Bray are pretty useless.  I also think that he *is* raising a
point that has been brushed against, but not properly discussed in the
many namespace holy wars that have come about on XML-DEV.

The point is: what happens when the real tools that real people use begin
to apply semantics to namespaces in conflicting ways.  Prospectors rush
into a standards vacuum, and boy do we have a standards vacuum here.

Paul is not the first to point out the essential contradiction of the
Namespace WG in saying that namespaces are opaque, meaningless strings in
one breath and then saying that they are URIs in the next.  So it's
been hashed out here and in the URI groups; and the gospel, with which we
smugly wave off all inquirers, is to say that that URIs were merely chosen
to make it easy for NS definers to claim unique territory.

Of course, the eyebrows go up a bit at this point since not every URI
scheme has provisions for such clear boundary.  My guess would be that
"urn:uuid:..." is the second most common URI variant after URL, and the
latest IETF draft has even given up the feeble approach of using hosts'
network addresses for UUID generation.  Now they recommend using random
numbers all the way.  Seems the very antithesis of "territory".

However, that's just an eyebrow-raiser.  Everyone uses URL for
namespaces anyway and the UUID URN namespaces are simply used in academic
exercises.  Once you get over it, a bigger problem comes about since the
choice of URIs as a territorial device effectively nullifies the
hand-waving claims of "no semantics for namespaces".  Tim Bray can rant
all he wants, but it's a lucky thing if this issue only comes up once every
six months.  I predict it's going to be an everyday issue very soon.

The issue was somewhat dormant while there was really nothing to expect at
the end of namespaces.  As others have pointed out in previous discussions
of this matter, the W3C introduced confusion in its fumbling attempts to
place matter where user agents resolve namespaces from recs.  They've even
gone as far as to use content negotiation, whatever *that* means for a
namespace URI (or is it at that point just a doppelganger regular URI?
Again, we want people to *use* this technology?)  But all that could be
passed of as a cheap convenience.

However, now we have XSchemas, and there is a sizable body of conventional
wisdom that suggests having an XSD at the business end of a namespace URI.
I'm not sure where this CW comes from, but I have heard and read it often.
It's not hard to see what Paul's apocalyptic "tool X" will be.  It will be
a well-intentioned XML processor that probles the document's namespace URI
for a schema and cheerfully throws around processing assumptions based on
what it found.  Of course we can all stand around, pull at our beards and
condemn the  manufacturer of that tool, but all they'll do is point at RDF
and SOAP and laugh at us.  And rightly so.

I don't want to claim I could make a better choice than the namespaces WG.
SGML old heads like to cluck at the whole namespaces idea as a hack, but
in my opinion the WG introduced a very practical and digestible solution
to a common problem.  Nevertheless, I think it turns out that the semantics of
namespaces are going to be a wild-card for interoperability and
automation.  In hindsight, maybe Paul's idea is a good one, of defining a
new top-level URI scheme, perhaps with in a Java-package-like form which
would still allow the supposed territory benefits of DNS.

Tim Bray:

"Once there is some general agreement as to what kinds of
semantics one might expect to attach to namespaces, and what
mechanisms prove to be the best for expressing those semantics,
then it will be possible to have a useful debate about the
meaning of namespace identifiers.  In the advance of such
agreement, the debate has been, and continues to be, an
outpouring of hot air which could be put to better use this
winter in helping alleviate energy shortages."

In the spirit of "worse is better", I think we need to begin this
conversation *now*.  I don't know what constitutes the benchmark of
"general agreement as to what kinds of semantics one might expect to
attach to namespaces".  I wonder whether it is anything attainable.  When
a subset question such as relative URI refs sparks a 1000+ message debate
and is settled with a controversial pronouncement, I hardly think greater
agreement is to be expected in the normal course of events.

All sides certainly have enough ammo to bring to a War over Namespace
Semantics.  Why should we not engage?


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python