thinking about "namespace pedantry"

in his essay titled "namespace pedantry"[1], tim bray argues that, if 
one uses terms which appear in a standard, one should use the terms in 
a manner which conforms to the standard. he is correct. in the strict 
sense. the problem is, the standard terminology at issue forces each 
reader, each dependant standard and each implemention to solve the 
equivalent of russell's paradox anew. which makes no sense. the only 
reasonable response is, "please, finally, fix this standard."

this discussion reaches back quite far. i was unable to coax the 
revelant entries out of lists.xml.org, but my recollection is that, 
bray, even at his most pedantic, allowed that, every application will 
likely construct some data object to collect the "names which are not 
in a any namespace". and, despite the necessity, that the application 
treat this object the same way as it treats data objects which are 
identified by iri - that is, as a set of names identified by a datum 
which is denoted by prefixes, and despite the recommendation's 
definition of a namespace, and despite the rfc2396 definition of a uri 
reference, the latter objects are namespaces, while collections of 
"names which are not in any namespace" are not.

which puts every dependant standard and application in the position 
where it must define an additional concept or data type, "not a 
namespace", which behaves just like a namespace, but is not called 
that. if an implementation does not do this, the computation which the 
processor implements is based on operations which are not closed over 
the respective model and its results are not defined. not a good state 
of affairs.

this issue confounds not just dependant standards and implementations, 
it wrecks havoc with the namespace recommendation itself. consider two 
examples. the first, from bray's essay:

<ns1:e1 xmlns:ns1="http://ns1.example.com/">
   <ns1:e2 a1="1" ns1:a2="2" />
   <e3 a1="1" ns1:a2="2" />
   <e4 xmlns="http://ns2.example.com/">
     <e5 a1="1" ns1:a2="2" />
     <e6 xmlns="" a1="1" ns1:a2="2" />
   </e4>
</ns1:e1>

while "all instances of the attribute a1 , are [by definition] not in 
any namespace whatsoever" every xpath processor will treat the term 
"a1" used to encode an attribute in the 
"uname:e2:http://ns1.example.com/"
as if it denotes the same name as the term "a1" in the "uname:e6:" 
element. even though, by definition, neither is in a namespace, "they" 
are identical. interesting state of affairs.
(one notes that appendix b of CR-xml-names11-20021218[3], the 
non-normative one which purported to describe "the internal structure 
of xml namespaces", is now an "appendix without any content".)

as a second example, consider the example given in 
"REC-xml-names-19990114"[2] in the section on uniqueness of attributes. 
the section describes as one of the criteria for namespace conformance, 
that "no element have two attributes with the same expanded name". 
thus, given the subsequent example:

<x xmlns:n1="http://www.w3.org" 
   xmlns:n2="http://www.w3.org" >
  <bad a="1"     a="2" />
  <bad n1:a="1"  n2:a="2" />
  </x>

an application must ensure that the first lexical term "a" in the 
element with the identifier "uname:bad:http://www.w3.org" denotes the 
same "expanded name" as the second term "a". where, under the 
constraint that, "for a name that is not in a namespace, the namespace 
name is null," the application might feel compelled to implement this 
set by predicate rather than by extension, that makes no difference to 
the nature of the set. i suspect that any xml processor which interns 
names pretty much ignores the distinction. as it should.

bray argues that there is some imperative to the proscription against 
namespaces named by the uri "". he offers, with reference to the first 
example, that

"This example also shows why you can’t have a “blank” namespace.  In 
the start-tag of e4 the default namespace is set to 
http://ns2.example.com/ , but then the empty string is used to unset it 
again in e6 .   Since the empty string is used this way, it can’t (by 
definition) be used to name namespace. "

this objection is unfounded. as this reader understands it, it concerns 
the identity of the name(s) denoted by the respective "a1" terms. since 
the recommendation already specifies that the default namespace binding 
does not apply to attribute names, it is not clear what this objection 
is supposed to mean. given the following,

<e6 xmlns="" a1="1" ns1:a2="2">
   <ns1:e1 xmlns:ns1="http://ns1.example.com/">
     <ns1:e2 a1="1" ns1:a2="2" />
     <e3 a1="1" ns1:a2="2" />
     <e4 xmlns="http://ns2.example.com/">
       <e5 a1="1" ns1:a2="2" />
       <e6 xmlns="" a1="1" ns1:a2="2" />
     </e4>
   </ns1:e1>
</e6>

this implemetor would expect every namespace-aware xml processor to 
treat the outer "uname:e6:" as if it denotes the same universal name as 
the inner "uname:e6:" and to apply the same constraints to the 
respective "uname:a1:" terms.

in summary, the "namespaces in xml" recommendation's specifications 
with regard to "names which are not in any namespace" are unnecessarily 
and unreasonably paradoxical. they impede rather than further processor 
implementation and the formulation of subsequent standards. they should 
be rewritten to reflect the intended behavior in a simpler, consistent 
form.

...

[1] http://www.tbray.org/ongoing/When/200x/2003/08/08/NamespaceOrNot
[2] http://www.w3.org/TR/1999/REC-xml-names-19990114
[3] http://www.w3.org/TR/2002/CR-xml-names11-20021218/#Philosophy