June 02, 2008, 1:50 PM — First up, a scope warning for this article. This is the first part of a two-part piece about XML. Here I focus on uses of XML in areas such as application configuration files, the exchange of structured, machine-oriented data, that sort of thing. In the second part, I discuss XML in document-centric applications such as content/document management and Web publication systems.
Much has been written and continues to be written about the "angle bracket tax". Now let us start by calling a spade a spade. XML is not a silver bullet and if you unilaterally spray it over your application space you can get into trouble. No amount of pretty-printing an XML file containing a SOAP message will make it look pretty to an application developer's eyes. No amount of pretty-printing a complex ANT script or a CFML script will make the conditional logic that these things often contain, easy to read or easy to process programmatically.
For many applications of XML you will come across, there appears to be a better, more optimal non-XML based solution possible. For any given data representation requirement you as an application developer/designer might have, there is a "better" syntax than XML for representing it. XML is sub-optimal for everything, or so it sometimes seems.
In my opinion, that is not a weakness of XML, it is a key strength. A strength that, if used wisely, pays significant dividends. However, it must be used wisely to be effective.
The most important thing is to ensure that you use XML to solve the parsing problems that you do not want to take on yourself. Tagging data can really cut down on the amount of work you have to do but only if the tags are in the right places. For example, the following example does not really help you process name in your application:
|
<name>Sean Mc Grath </name> |
The problem is that your application must do the tricky part - splitting the first name from the second name. This would be much more useful:
|
<name> <first>Sean </first> <second>Mc Grath </second> </name> |
The second most important thing to do is not complicate your life by using complicated XML processing APIs. There are times when you absolutely must use event-oriented parsing techniques like SAX but most of the time, you don't. Life is much easier if you load up the XML document and "walk" it node-by-node or "pull" parts of it, token by token using pull parsing.
The third most important thing to do is to consider internationalization. Now if you are happy to live in a US-ASCII world, this doesn't apply to you but for everyone else, listen up. Detecting and properly handling character encoding is hard and ugly. XML - for all its sub-optimality - provides a workable framework in which to handle character encoding without too much heartache. Believe me, you do not want to end up re-inventing yet another Unicode encoding detection algorithm.
The fourth most important thing is to create a schema and use it for validating your XML files. I have lost count of the number of XML applications I have encountered where the developers use a non-validating parse of the XML and then proceed to custom code up basic structure rules that can easily be handled using a schema language. My own preference is Relax NG but DTDs are still very useful and, if it is the only choice open to you, XSD is better than nothing.
