I think I've mentioned before the time that the resident XML expert at my old place of employment emailed the software development group an article off the web telling how great XML was and how many ways we could use it in our day-to-day projects. Trying to be cute, but at the same time trying to get what I believed across, I did a quick search and replace on the article to insert ASCII for each instance of XML. Easy read and written, a standard for storing and transmitting machine-readable information, etc. Was thinking about how I didn't use XML in my latest app and I don't know that I've much changed my mind yet.

Don't get me wrong. XML is great. It imposes a fairly forward-thinking structure to your applications' information, and does a great job bridging the gap between machine-readable information and human readable info. Most important is that "X" in XML, as it's awfully easy to take an XML schema and add a few more bits of information to a certain section/object without ruining backwards compatibility. That's a big deal.

At the same time, it's much easier to "inputFile.readline()" than it is to learn the overhead associated with an XML parser. Not to mention all the extra minute rules you have to learn (like the "reserved 'id' attribute must be unique for each element" bit) to be strictly compliant. Of course there's also the fact that you have to learn a brand new pseudo-language, XPath, to extract bits from your XML file though ANSI-SQL with a few extra keywords would have done every bit as well - heck, better.

XML has a little of the "New Coke Syndrome" (which I've started explaining in a draft blog entry I've got concerning Java's Swing) that's all too prevalent in computing and standards. In brief, lots of people smarter than us got together in a clean room and put together the best ideas they could about a certain subject and came up with a new way of doing things. Problem is, though everyone might have theoretically preferred the new taste when polled in a similar clean room environment, when it comes to practical action things fall short of the mark. SOAP is another neat idea that, in practice, falls a little short.

You shouldn't have to learn so much esoteria to learn and use XML in your apps. And if that's the case, then strict XML's not such a good fit after all. If you're writing the next great business-to-business application, use XML. There's so much there already decided for you that you'll save tons of time and hassle not having to decide what's going to be "your data exchange method" between workgroups in your project. But if you're just hacking a quick website that'll take a few "man-months" to finish or writing a stand-alone app that only four or five people need to support (regardless of how many are going to use it), use the simplest means necessary for simple app preferences or configuration files. Not only will you make the app smaller, you won't be adding months to a new programmer's ramp-up time when they join the team. Only if you find yourself bogged down in the creation of your files' formats should you default to using XML. Be careful you're not headed for overkill.

Now at the same time, make sure your application is written in such a way that whatever you use for the backend doesn't make much difference. If you're reading from the same pref file (much less writing) in three different locations in your app, it's time for a refactoring. If you write your code well, switching from ASCII to a RDBMS to XML and back shouldn't be a bigger problem than rewriting one set of I/O routines. I'm not really against XML; don't get me wrong.

Ah, forget it. I'm waffling like Clinton. I give up. Sometimes it's good, depending on your coworkers, to force XML just so that you don't have to try and describe how to make code forward compatible and extensionable. It'll save you time in the future by not having to rewrite code by having your team use this standard. I'll just call its applicability situational and leave it at that. Perhaps another day I'll finally figure out what I think about using XML for non-b2b applications, but this apparently ain't it.