XML and the document format mind bender

March 16, 2007, 1:01 PM — XML has been around now, in its final fully fledged form, for more years than I care to remember. Having played a small part in its original creation, thinking back that far makes me feel old.



Explaining the whys and wherefores of XML to non-technologists and technologists alike has always been an interesting challenge. One could be forgiven for thinking that the value proposition has at this stage been fully trashed out. Either you believe in the value proposition or you do not. Either you are applying XML sensibly in your business or you are not. Surely such matters would be well and truly baked at this point?



Not so. Not by a long shot unfortunately. Here is the problem in a nutshell: it is real hard to explain to non-technical folk why it is that keeping your information in XML is not - in itself - a guarantee that any sizable benefits will accrue.



As I have said before in this column [1] and elsewhere, any old nasty, crufty, effectively-proprietary-silo of information goo can be 100% XML compliant. Being in XML lifts information one small step up the information ladder - it is no longer completely opaque outside the four walls of the application that created it. However, it is quite a small step up what is quite a long ladder. Would I prefer to start with XML rather than a non-XML format for most document-centric IT tasks? Yes. For sure. Does XML - in and of itself - make it straightforward to move data from one application to another or to automate document processing? No. No it does not. It can, but it is not an automatic side effect of using XML.



Another nutshell (this is the mind bending one): information can be utterly, utterly application-specific and still 100% XML compliant. Your ability to work with data outside of the application that created it is an optional - highly desirable, but optional - attribute of an XML-based system. It can easily be the case that one proprietary application from one vendor is the only realistic tool for manipulating your XML data. It can easily be the case that without the application in question, the value of the data is significantly diminished and the rationale for using XML in the first place greatly reduced.



Many non-technical (and some technical) folk have difficulty understanding this fact. A common conversation goes something like this:



Slightly technical senior manager person who reads a lot of trade press: "We should move all our documents to XML because all sorts of great things will become possible...If you have time, I can walk you through the benefits..."



Non technical senior decision maker: "That sounds great but according to the blurb I read, our new word processor/DTP/Web Editing tool stores all its information in XML and/or seamlessly imports/exports to XML. So we get all these good things you mention for free as part of our next application upgrade? Excellent!"



Why is this a mind bender now? Because we are on the verge of a world in which all mainstream document-centric tools do XML natively. Most of them will store their files natively in XML. So if the word processor/DTP tools you know and love all do XML natively, why do you need to do anything at all to benefit from XML?



Explaining the flaws here is left as an exercise to the reader. Figuring out how to explain the important issues raised to non-technical senior management in the course of an elevator ride, is left as a Ph.D. thesis suggestion.



It is entirely possible to have all the benefits of XML and yet retain the ability to just use user friendly, commodity off-the-shelf tools. However doing so - especially with complex document-oriented information - requires something more than just slapping an XML label on the file format.