Namepaces in Xml - the battle to explain
Over the weekend a few people came to me with questions on Xml, C#, Schema and Namespaces. It seems that Namespaces is quickly displacing Xml Schema as the thing people "like to hate" - well at least those that are contacing me now seem to accept Schema as "good".
Now, the concept of namespaces is pretty simple, but because it happens to be used explicitly (and is a more manual process) in Xml people just don't seem to get it. There were two core worries put to me - one calling it "a mess" and the other "a failing". The whole thing centered around having to know what namespaces you were actually using (or were in scope) when selecing given nodes. So in the case of SelectNodes(), you need to have a namespace manager populated with the namespaces you intend to use. In the case of Schema, you generally need to know the targetNamespace of the Schema when working with the XmlValidatingReader. What the guys I spoke with seemed to dislike is that you actually have to know what these namespaces are. Why bother? Don't use namespaces and just do your selects or validation. This was almost what they were hinting as the preferred method, but this misses the point of namespaces and perhaps the best way to illustrate this is to step back into procedural land and think about programming in the .Net or Java worlds.
Imagine you created a bunch of projects each containing a single class called "ShapeManager", each class containing an implementation for some kind of shape (circle, triangle and so on) depending on the project you are working in. You then reference each assembly in your master "ShapeDrawer" application. So you go to create an instance of ShapeManager.... what happens?
Well, in my test case, you actually get an instance of the first class and the following warning during compilation :
'ShapeManager' is defined in multiple places; using definition from ...
Now is this acceptable? When we now have the a class ShapeDrawer that contains multiple implementations but which all fall under the same namespace (or no namespace rather). So when we want to use a specific implementation what do we do? How do we access that? What is our solution? Heck .Net and Java suck!!
Well, one technqiue is that we may create a namespaces such as ShapeDrawer.Circle and ShapeDrawer.Square (ignore any more advanced techniques for just now, it' not a programming tutorial) and each will contain the implementation for that type of object. In fact it is failry common practice to group similar types of functionality under specific namespaces. Sure .Net and Java provides a whole bunch of other techniques and possibilities but let's just stick with the fundamental concept of namespaces across the baord.
Also consider where we want to create a new version of some object. Thankfully .Net is doing some great things to move away from DLL Hell, but it does this by a bunch of techniques that annotate/sign the assembly with some simple (or even complex) information on version and so on. All this is stuff we have been asking for for years (especially those from VB or scripting worlds).
So why, oh why when it comes to Xml do we seem to miss this point? Xml namespaces simply combine some of the great faetures from OO and .Net into one. We can group similar types (elements, attributes and so on) into one semantic group as defined by its namespace. So if we use the element "screw" in the namespace http://mytools.com/taxonomy then it is completely different from using the word "screw" which is part of the namespace http://accountants.com" ( no offence any accountants:) ). Similarly, our namespace can help us manage version information (albeit fairly simply) and other types of information you may want to signify. Without the namespace everything becomes practically typeless and versionless - we're back to a world containing only single classes or Variant data types on the web. All elements are just System.Object (well a little better since then have names).
Hell it's hard enough imagining a local project using no namespaces but in my experience (and the question at the weekend was also the same situation), Xml docs and Schemas come from different places - some online, others from one software company doing part A of the project and passing you the output. Imagine all of this with no namespaces. Imagine a bunch of assemblies with no namespaces in a major project.
Xml with no namespaces is akin to DLL Hell. Sure you can get away with no using them in some cases, but you can also get away with Variant all the time. Difference is we have come to recognize that types and groups of stuff are a good thing. The quicker you come to realise the importance of namespaces the better. You use them all the time in the procedural world and maybe now you might understand why you should use them in the Xml world ALL THE TIME as well.
Any comments and/or pointers on this can only be appreciated. The quicker we can get something that explains namespaces to everyone the better IMO.
vtgo.net