XML is quite common nowadays, especially in the application integration business that I am involved in. However, I still see companies making big mistakes when they decide to start using XML (for example as the exchange format with their business partners). This series of posts is about mistakes (or at least clumsiness) in using XML that I noticed during several projects.
No use of versions in namespaces
In the previous post I already explained the usefulness of using namespaces in your XML schemas. The next improvement would be to make a version number be part of the namespace. Imagine if you don’t do that and you have to modify your schema. And with modifying I mean a serious change like adding a mandatory element to your schema. If you make this change then all systems and clients using your schema for their interaction will fail to do so as long as they haven’t changed their side of the interface. So actually you are forcing others to make modifications to their system. If I were a client of such a supplier I would definitely be unhappy with this kind of actions.
A nice way to avoid this situation is when you add a version number in the namespace of your schema. In that case you can create a new schema with a new namespace.
For example, the old situation:
xmlns:tns=”http://www.pascalalma.net/message
becomes
xmlns:tns=”http://www.pascalalma.net/message/v01_0
Now you can let the users of your schema decide when they are going to use the newer version. Of course you can provide a roadmap about when which version will become deprecated or even unusable.
This post concludes the series about using XML in real life projects. There are a lot more issues to discuss but I thought these were the most relevant to share. The final thing I want to mention is that you should use XML as meaning to get at your goal, it should not be the goal itself.
The Pragmatic Integrator 