Robin Berjon

XML Bad Practices

Non-HTTP Namespaces

One cause of confusion around namespaces is that many of them use a URI with the http scheme. People expect there to be something at the end of that URI. The fact is: there should be, or at the very least we should act as if there could be.

While there is no generally accepted way of defining namespace documents that live at the location pointed to by the namespace URI, the good practice is to place an HTML document there with links to documentation about the language, to schemata describing it, perhaps even style sheets or tools to go with it.

Not only is that the friendly thing to do so that humans can easily find the information they need, but it is also forward-looking: if at some point there is enough momentum behind reaching agreement on a way of embedding information in such documents then programs could automatically retrieve information for various purposes (e.g. an authoring tool could see a namespace it doesn't know and go fetch a default style sheet and schema for it, or a user agent could download the XBL2 required to support it).

That is something that can't be done with URNs, and even less with made-up schemes such as antlib: or clr-runtime:. With such approaches you find yourself not only unhelpful to people using your vocabulary, but very much stuck in the present.

A sadly common subset of this mistake is to have the namespace point directly to a DTD or XML Schema (e.g. the day you decide to switch to another schema language, or to update the language version without changing the namespace the tight integration is going to be an issue.

A particularly nasty variant is to use namespaces to point directly to an implementation of the language they describe. The canonical example here is from Microsoft Silverlight (which uses XAML). In XAML, custom components reside in a namespace which points to the DLL assembly that is to be used to render them.


This nullifies the whole point of shipping XML rather than code in the first place, and is basically as close as one can get to implementing a locked system in XML. Good luck for when you wish to change your implementation strategy without having to update all of your data!

This article is part of a series on XML Bad Practices.