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:

1. byte-for-byte string comparison of the namespace name as given
2. 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; "