Anne van Kesteren complains that the relationship between XML Namespaces and XML attributes bugs him, and I think that his annoyance might be justified. It’s been many years since we did the 1.0 Namespaces spec in the old XML working group, but as far as I can remember, the thinking that won out (not unanimously) was that attributes were similar to variables in programming languages: unqualified attributes were like automatic variables, scoped to a single element instead of a single function, while namespace-qualified attributes were like global variables:
int foo; void adjustFoo () { int bar = 3; foo = foo + bar; }
The foo variable has a scope outside the adjustFoo function, while the bar variable does not. Similarly, in
<n:info xmlns:n="http://www.example.org/ns/n"> <n:record n:foo="3" bar="4"/> </n:info>
The n:foo attribute has a meaning independent of the meaning of the n:record element, while the bar attribute does not.
Sense or Nonsense?
Does that make sense to you? If not, don’t feel bad: drawing analogies between markup and programming code is a dubious undertaking at the best of times. Unlike the foo variable, for example, the n:foo attribute doesn’t have a global value space, only a global meaning.
I do think that the idea of globally-defined, namespace-qualified attributes (like rdf:about, xml:id, xlink:href, etc.) is a very useful one. We messed up, though, by adding this extra level of complexity with unqualifed attributes (they should have just inherited the parent element’s namespace) — in other words, we didn’t choose the simplest thing that could possibly work. It’s too late to change Namespaces now, though, and any attempts to codify or clarify things since Namespaces 1.0 seem only to increase the confusion.
Bugs him, actually π
Thanks for the explanation. It was in line with what I expected it to be although taking programming languages in account was something I had not yet considered.
Oops — thanks.
Pingback: Bill de hΓra
Pingback: Martins Notepad