Plug In to SQL Server 2K
By Michael Floyd
One of XML's dirty little secrets is that it's not always the right solution for every problem. Case in point: I was recently instructing a group of students in methods for converting database data into XML. One scenario calls for retrieving data through an ODBC connection, and marking up the results with XML. Once the data is in XML form, you can choose to apply a transformation to the result set, or stream the markup (the XML data) directly to your client application. After going through this process, the response I often get is, "That's great, but what's the benefit of doing it this way?" The fact is, database developers can already stream data to clients quite nicely.
If all you're trying to do is present data in a browser, then going through the extra step of marking it up just so you can use XML may seem ridiculous. And if that's your goal, then I say you're right. Keep the status quo and don't give XML another thought. But if you plan to exchange your data with applications outside your control, you may want to take another look. Consider a newly acquired business partner that needs you to provide data in a specific format. It's easy enough to rewrite your application to include an option for outputting data in that format. But if you have hundreds of partners, the task isn't so easy and your application becomes more fragile. Rather than become a data translation specialist, wouldn't it be better if you could simply say, "Here's the XML—go translate it yourself?"
Data exchange is one reason why vendors like Microsoft are adding the ability to generate XML from their products.
