Using Too Many Namespaces

Of course, there can be too much of a good thing. I wouldn't say that using too many namespaces is a mistake in and of itself, but there is a point at which it does make processing a document — not to mention authoring one — rather too difficult.

The first item that typically springs to mind when people think of an excess in namespaces is RDF, but that is not the best of examples. It is arguable that RDF could have made things simpler, perhaps notably by making sure that the RDF Schema namespace would never need appear in RDF instances, but overall it was designed to be a very open system which would freely mix properties from a large variety of independent sources — it is to be expected that instances would often use many namespaces.

A better example is one that, thankfully, did not come to pass. At some point in SVG's history, one participant argued that SVG should push the toolbox approach as far as possible. Since SVG is defined by multiple modules that cover different features (structure, geometric elements, gradients, filters, animation, etc.) and since those modules can be reused independently, they should all be split up into separate languages — each of them with different namespaces. A quick count shows that that would define around 17 namespaces instead of one, and that even the simplest documents would require at least seven or eight. A less radical but similarly painful idea is that each new version of a language should put its new features in a different namespace.

From a processing point of view that would cause no problem, but it would make the language impossible to author. There is no value to placing language modules in different namespaces, and there are far better solutions to versioning. To paraphrase what is now a cliché, one should use as few namespaces as possible, but no fewer.

One mistake that SVG did make however is not taking the notion of a host language far enough. Some languages are designed to be reused in other languages, and have little reason to exist on their own. Two good examples are SMIL Animation, and XML Events. There is little point in identifying these languages as separate when they are embedded in another: indeed, what is the point in a generic animation processor understanding that an animation is being applied to a circle element if it does not understand what a circle element is? In such cases there is no point in placing those elements in their own namespace and they can simply be "hosted", which is to say that basically their semantics and processing are defined in another language, but they are absorbed into the host. SVG did the right thing with SMIL Animation by hosting it thus, but the wrong thing by not doing the same with XML Events (not to mention XLink). As a results, in SVG 1.2 one needs to declare an extra namespace just for events, even though there is no way in which a listener element will have any independent meaning.