After 2 weeks and 721 messages, the debate has left
behind a moderate path (absolutization) and bounced on to a
"semi-serious
proposal".
Paul W. Abrahams reminded the list of the apparent
intent of the namespaces specification:
"OK, the folks who brought the namespace
spec into the world
are of one voice: namespace names don't mean anything. They
are just unique identifiers."
and David Carlisle reminded the list of the reasons why
URIs
had been chosen as
namespace identifiers:
"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."
Clark C. Evans responded to these discussions by acknowledging
that:
"Since, from my listening, there seem to
be two camps:
a) Those who believe that a namespace
name should only
be used for identifying, nothing
more.
b) Those who believe that a namespace
name should also
be used for locating in addition to
identifying."
Evans proposed to differentiate these 2 cases through the
URI schemes (data: for identification and http: for
retrieval) and Tim Bray proposed to move
to the second one:
"At the end of the day, there are only two
consistent positions regarding
comparison and equivalence of namespace names:
- byte-for-byte string comparison of the namespace name as
given
- byte-for-byte comparison of the indicated resource after
retrieving it
All of the intervening positions are fatally compromised
IMHO. #1 has
the advantage that it's cheaper and requires less
infrastructure. #2 has
the advantage that it really does connect namespaces to the
Web in a deep
way that's consistent with the underlying architecture,
whatever that is.
I could live with #2. Given a W3C recommendation on
what dereferencing
the namespace name should yield (I recommend a packaging
document compromising
a single (potentially large and complex) extended XLink), I
could be
enthusiastic about it."
This was countered by Simon St. Laurent who put forward
the bandwidth
issue:
"I've got to complain about that simply on
grounds of the amount of
infrastructure required to process a 'name'. Caching
resources, which
could conceivably be enormous, and which might very well not
exist?
Explaining that to the folks trying to process XML
within PDAs and even
smaller devices (which were an explicit goal of XML 1.0)
sounds like a task
for the extremely brave. "
Simultaneously, on a parallel thread, John Cowan proposed
to separate
the notions of namespace
names and
namespace URIs "constructed by
prepending "data:," to the namespace name" reminding
that namespace URIs were important for RDF
not only
to reference schemas, but to be considered as RDF
resources:
"namespaces are resources that have URIs
and so can be the subjects
and objects of RDF statements, though they don't
have the
same URIs that they were (assumed to) have before;
"