thinking about "namespace pedantry"

[james anderson <james.anderson@setf.de>]

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