The null namespace bugs me. Actually, namespaces bug me. There are a lot of issues regarding namespaces, but lets start with the null namespace. Here are two examples:
<foo/>
<foo xmlns="tag:example.org,2005-03-12:foo" bar="test"/>
In the first example, the element FOO is in the null namespace. In the second example, the element FOO is in the tag:example.org,2005-03-12:foo namespace. The attribute BAR, however, is in the null namespace. It is quite important to know that attributes do not inherit the namespace from the element they are declared on. Child elements, however, do inherit the namespace of their parent element. To make it more confusing, child elements do not inherit the namespace their parent element has when the parent element uses a qualified name. For example:
<f:foo xmlns:f="tag:example.org,2005-03-12:tag"> <bar/> </f:foo>
The element BAR is here in the null namespace because there is no default namespace declared on its parent element. There is a namespace declared for all elements using the form of f:local-name though. (See also Qualified Names in namespaces in XML.) Of course, that namespace declaration can also be used for attributes. And it can even be used for attribute values. Using it in attribute values is quite common in XML Schema. I mentioned that in my XForms post which also contains an example of usage.
In a post on XML 2.0 Norman Walsh suggests assigning the null namespace to a URI. (Perhaps IRI by now.) I can see how that solves the problem for elements. For qualified names inside attribute values or as content he has another solution that looks quite good and solid. However, attributes seem to be missing. Also, if every attribute would be assigned to the same null namespace URI that might create some problems. Attributes that have the same name but are applied to different elements might have a different affect or other semantics. I assume that assigning them all to the same URI takes that away.
Originally I was planning to say something about the “nearly-null namespace” they are introducing for XForms 1.1, the problem that XML 1.0 and Namespaces in XML are separate specifications and some other little notes as well, but I don’t really like long entries.
Although I've known this to be the case for a while, I've never really understood it. Why don't attributes inherit the element's namespace? Do you, or anyone else, know the reason for this odd behaviour?
I’m not sure what the actual reason behind the decision is. However, as expressed in the article, I think it is to make the relationship between the element and the attribute more clear. If an attribute has a namespace of its own it isn’t logically bound to a particular element anymore. (You can of course limit this by a DTD or schema as well, but I think that is different.)
Is that the reason why XHTML 1.1 doesn't allow the id attribute on the html element (and the need for xml:id)?
No. The need for xml:id is there because people don’t want to use DTDs to say a particular attribute is of type ID. (That is currently the only way to do such a thing for web browsers and only if the DTD is inline. For non web browsers you can use either a DTD or schema, but it still sucks you need them.)
The reason XHTML 1.1 does not allow the ID attribute on the HTML element is different as well. Basically it has to do with the fact that XHTML 1.1 is based on the XHTML modularization which has not been updated to allow the ID attribute on the root element. XHTML 1.0 was updated.
I expect all future versions of XHTML and HTML to allow the ID (or xml:id in case of XHTML), CLASS, LANG (or xml:lang), DIR and TITLE attributes on all elements.
Anne van Kesteren complains that the relationship between XML Namespaces and XML attributes bugs him, and I think that his annoyance might be justified…
I do find the system of namespaces in general to work pretty intuitively, however the null namespace on attributes is indeed plain rediculous and confusing.
Unfortunately, it can’t be changed anymore now. And in practice it isn’t that bothersome, just confusing.
~Grauw
The correct expression is “not in a namespace”—not “in the null namespace”. Also, the declarations are scoped to a subtree but the namespace is not inherited. In some cases both the parent element and the child element happen to be unprefixed and are in the same default namespace thanks to being both unprefixed—not thanks to inheritance.