October 19, 2003
@ 05:52 PM

Rob Volk writes

Is XML Evil?

About a month ago I was asked by a contractor I work with who needed to import some very plain, fixed-width, ASCII text file data into SQL Server. In fact, this SQL Team post is very much like his situation, in that he also was going to convert PLAIN, FIXED-WIDTH, ASCII TEXT (did I mention that already?) into XML and THEN import it into SQL Server...  <snip />

Fortunately (!) we use SQL Server 7.0 so none of the XML extensions were available for him to use. As it turned out I already had a bcp format file that could read the text format he needed to import. So, with ONE LINE OF SQL, I was able to do something he would have had to write over 100 lines of C# to parse the file, XML-ize it, and then save out to ANOTHER FILE so that he could import it (using about 12-20 lines of SQL, or more) Using bcp also would've entailed one DOS prompt command. Even DTS would've been harder to use to accomplish the same thing.

So, exactly how is XML making this process easier? Where is the ease of use and interoperability it's supposed to provide? I'm completely astounded that so many people have been so thoroughly brainwashed by the XML hype that they not only see it as the best way to do something, but as the ONLY WAY TO DO IT.

Situations like the above were my motivation for writing the article Understanding XML on MSDN. Using XML for a software development project buys you two things (a) the ability to interoperate better with others and (b) a number of off-the-shelf tools for dealing with format. If neither of these things apply to a given situation then it doesn't make much sense to use XML.

Applying the interoperability litmus test, unless the data in the text file in the situation described above is going to be shared with partners there really isn't any reason to convert it to XML to gain interoperability. Even then one could argue that it may make more sense to just pull out relevant data from the database and convert that to XML as needed when data needs to be exchanged with partners. As for the gains from off-the-shelf tools, given that there were already tools existing for the format used by the text file that performed the required task there really wasn't anything to be gained by converting it to XML.  

Applying this litmus test makes it fairly easy to figure out when to use XML and when using it isn't such a good idea. This is one of the reasons I consider articles such as Parsing RSS At All Costs as setting a bad example because they encourage the notion that it is OK to produce and consume ill-formed XML. Of course, once you do that you can't really interoperate with others and traditional XML tools cannot be used on the ill-formed documents so you might as well not be using XML.


 

Friday, July 16, 2004 8:16:32 AM (GMT Daylight Time, UTC+01:00)
Rob I agree that, in many situations, it simply makes no sense to convert simple data into XML for interchange between two systems. However, I think there is one situation in which making this extra step is really useful. That is, when you're trying to transfer data represented by a number of entites that have relationships constricted by RI constraints. In this scenario, it really is very useful to have all the data in one structured file that can then be parsed and used to update the data intelligently. The alternative solutions - either some form of structured csv file or different files for different entities that must arrive together - are messy.
Jon Boxall
Comments are closed.