The Effective CIO

No Free <Lunch> June 18, 2008

I’ve noticed a disturbing trend in sales pitches and product literature these days.  When I ask if a particular product can easily import or export data with our existing systems, vendors often reply, “Of course!  We can export XML!”

XML, for those readers with actual lives, stands for eXtensible Markup Language.  It is a way to express data in a way that the data can be processed and managed in fairly standard ways.  Essentially, you surround your actual data with keywords, attributes, and plenty of angle brackets to make it more understandable by computers and humans.

To hear some people tell it, anything expressed in XML is instantly recognizable by any other computer anywhere on earth.  In fact, if you place two systems that use XML at opposite ends of your data center, by the next day they’ll have met in the middle, network cables and power cords wrapped around each other in an XML-inspired embrace.

Please.  As we like to say in the computing business, “bits is bits.”  Data, no matter how it is represented, can only be understood by a system that has been explicitly programmed and tested to process that data. XML may make the data easier to process, but someone still has to write, test, and support that code.  And in many cases, XML makes things more complicated.

For example, today is June 18, 2008.  Here is one way to represent that date for transmission between two systems:

20080618

I’ll bet most of you have decoded this particular data representation: four-digit year, two-digit month, and two-digit day.  Here is the same date in a bit more old-school format:

08170

Slightly more cryptic, but not too hard to program: the first two digits are the year and the next three are the day of the year (June 19 is the 171st day of 2008).  Notice the retro, pre-2000 two-digit year?  It’s like shag carpeting for programmers!

Here is the date in one potential version of XML:

<date>
   <day>18</day>
   <month type=numeric>6</month>
   <year>2008</year>
</date>

More understandable? Maybe.  Self-documenting?  Sure.  Easier to read, parse, and decode?  No way.  You’ll need an XML parser, a definition document for this version of XML (known as a DTD), and a competent developer to make sense of this particular data stream.

When all is said and done, very little in computing is inherently easy or automatic.  At every level, someone is designing, building, and testing all the little pieces that make that level work.  You may build on that level, but you’ll have issues of your own to deal with.  Never underestimate the difficulty in making systems play well together, and never believe what the salesmen say without digging into a details first.