What are XML namespaces for?

Solution 1:

They're for allowing multiple markup languages to be combined, without having to worry about conflicts of element and attribute names.

For example, look at any bit of XSLT code, and then think what would happen if you didn't use namespaces and were trying to write an XSLT where the output has to contain "template", "for-each", etc, elements. Syntax errors, is what.

I'll leave the advice and pitfalls to others with more experience than I.

Solution 2:

Why do XML namespaces exist?

Because, back in 1997, some very influential persons in the W3C wanted them, and would not take no for an answer. Even when it was demonstrated, I dare say conclusively, that there were better ways to solve the "problem" they thought they had, they still wielded their influence to have their desires written up into a W3C Recommendation.

The biggest whopper in the by now extensive mythology surrounding XML Namespaces is that there is technical merit to them. (This is the downstream effect of a Recommendation simply existing and thus occupying mindspace - "gee, there's gotta be a (good) reason!" - as opposed to a forgetable footnote somewhere.)

Much pain, no gain.

When should we use them and when should we not?

You should never use them if you can help it. Unfortunately, the relentless promotion of this BAD[*] device by interested parties has fostered a clusterf*ck of specs today that make it practically impossible not to have to contend with XML namespaces at some point or another. So, even if you eschew XML namespaces yourself, you will find namespace-encrusted crud coming at you from all directions, or worse, toolsets that simply refuse to work unless you feed them such crud.

What are the common pitfalls when working with namespaces in XML?

One very common pitfall is in using Xpath expressions with documents where a namespace has been "defaulted": the namespace will have to be explicit in the expressions. Another issue is using them "correctly" when constructing documents: they create problems out of thin air.

Also, how do they relate to XML schemas? Should XSD schemas always be associated with a namespace?

There is no necessary relation, except that the XSD Schema spec was developed at a time when just about everyone on the committee had the XML Namespaces bit in their teeth. So they worked it in as deeply as they could. It's possible, nevertheless, to use XSD schemas without namespaces, but it's a steep uphill slog as just about every toolset supporting XSD schemas assumes that you will be "wanting" to use namespaces.

[*] BAD = Broken As Designed

UPDATE: An old essay on this non-solution to a non-problem.

Solution 3:

It's nearly the same as asking "why do we use packages for Java/C#?":

• reusability: You can reuse a set of tags/attributes you define across different types of xml documents.
• modularity: If you need to add some "aspect" to your XML; adding a namespace to your xml document is simpler than changing your whole xml schema definition.
• Avoid poluting the "main" namespace: You don't force your parser to work with a huge schema definition, just use the namespace you need to.

Solution 4:

The biggest pitfall IMHO is human-interaction interpreting documents e.g. to develop code to process an XML Doc. It is too easy to focus on the literal expression of the document rather than the infoset result of parsing the document.

e.g. the following nodes

<a xmlns="uri:foo"/>
<foo:a xmlns:foo="uri:foo"/>
<bar:a xmlns:bar="uri:foo"/>

are all semantically identical - yet very different to the naive eye.

The 1st example yields a very common mistake developing XPaths - missing the fact that "a" is in a namespace - thus //a yields no matches. (or worse still matching nodes in a different namespace!)

The 3rd example opens another flaw in understanding - that the prefix text is semantically significant. When parsing documents with XPATH I can declare any prefix I like for matching as long as it's uri matches those of the document.