The idea of being able to stitch different vocabularies together is genius.
That said, I haven't seen a single XML toolchain that doesn't have some bug or, ahem, irregularity, in how namespaces are handled. XLinq comes pretty close to being correct though.
I feel they should be as simple as (eg) Java packages; but the problem has different parameters in Java: there's less chance of collisions in Java, because you're just writing one module; whereas one XML document can merge different sources - it's as if arbitrary Java modules, written by unknown people, were combined into the one file.
Some people use the namespaces in what appears to be a decorative manner. Some people mandate that the prefix be a certain thing <x:tag xmlns:x="thing"> works while <y:tag xmlns:y="thing"> doesn't, proving they're doing it wrong under the hood. Some things get it right with xmlns:*, but don't understand what the bare xmlns itself means, so they only trigger namespace logic if there's a colon in the tag. I've seen cases where the namespace is declared, then used out-of-scope like it's a global declaration or something. I'm still waiting to encounter the standard or software that actually uses them correctly. And despite this listing of wrong answers it really isn't that complicated....
My biggest issue with namespaces is the dichotomy between namespace URLs and namespace prefixes, and most people not understanding that prefixes are actually aliases for the URLs. For that reason, I quite like Clark's notation for namespaces (which is used by ElementTree and LXML), it makes the relation between element and namespace much clearer. Shame you can't use it in XML documents or XPath queries.
Also, that the default namespace only applies to elements, not attributes. I kind-of understand why they did that, but it's still very annoying.
> Some people use the namespaces in what appears to be a decorative manner. Some people mandate that the prefix be a certain thing <x:tag xmlns:x="thing"> works while <y:tag xmlns:y="thing"> doesn't
Oh yeah. Isn't it maven or something, which does that? Or did? I know I encountered it once or twice and I was using ElementTree 1.2 at the time (the one that went into the Python stdlib... and still is) and it doesn't keep track of XML namespace aliases (or defaults for that matter, and doesn't let you set them short of hacking through the private and undocumented namespace map) so everything comes out as `ns0:foo`, `ns1:bar`, ... Perfectly valid, and then you have a retarded tool which doesn't actually understand namespaces (even though the example documents say you need a namespace spec) and want an element called `foo:bar` and not "the element `bar` in the namespace http://foo.com.
> Some things get it right with xmlns:* , but don't understand what the bare xmlns itself means, so they only trigger namespace logic if there's a colon in the tag.
When that happens, somebody ought to get shot. Default namespaces are one of the most basic parts of namespaces (and it's not that hard to parse, though production might be a different issue).
> I'm still waiting to encounter the standard or software that actually uses them correctly.
libxml2 tended to work quite well in my experience (mostly though lxml), though I don't doubt I just missed its bugs.
edit: damn it, is there no way to escape those damn asterisks in yc?
When I say I'm still waiting to see the software that does it correctly, I mean like end-user-level software, not the parsers.
They're nice, but generally misimplemented, misunderstood and misused.
> I'd just prefer them to be declared at the start of the document.
I'm not sure why. It's nicer when you have to read the document yourself for sure (but then again, XML is rarely actually nice to read), but when mechanically processing it it shouldn't be relevant: just use each node as a (ns, name) pair where ns is the namespace's URI (not its alias) and name is the localname. In that case, what does early declaration bring to the equation?