It’s time to step back a bit from the syntactical particulars of XML and consider the bigger picture. While XML is being hawked as the answer to all of your data woes, you’ll find that like many other solutions, it has its place. Consider how you are applying XML as we look some situations that are ideal for it and some that should be handled by other technologies.

XML as a selling point
Software projects often have specifications that are needed to make the product both functional and usable. But sometimes, the spec may be there not for functionality, but rather to help sell someone on the product. Enter the problem of marketability.

Just because the project or product does what it’s supposed to, does it well, is easy to use, and everyone loves it doesn’t mean that the software is going to sell like hotcakes. Something may need to be added to make customers think they are buying the latest technology. Or something may need to be added to sell the project to an executive who believes the company needs it to compete. So to help with the burden of selling, marketing and sales departments (and sometimes the IT department) often use industry buzzwords when describing their products to convince the client that the product is “new and exciting,” to help close the sale, or to convince management that a project should be approved.

Unfortunately, XML has become a cliche, attached to everything under the sun. Not all products need to be XML-enabled or XML-compatible. What’s worse is that not all products that claim to be XML-enabled or XML-compatible actually are.

A rose by any other name
Sometimes, you have to say an apple is an apple. It’s not an orange. It’s not a monkey. It’s an apple. That’s the case with XML. XML is a markup language used to describe data; in other words, it’s a data format. It’s not a programming language any more than Notepad is an “HTML editing tool.” XML is really just an enhanced, feature-enriched delimited data file. It’s better than the traditional fixed-length ASCII file and comma-delimited files because it allows the user (or system) to implement changes to the structure of the data without affecting the process that reads or writes the data (to a certain extent). Processes that read and write data in a transactional, document-oriented format are excellent candidates for using XML. Further, processes that have changing or dynamic data format needs are the best candidates for taking full advantage of the features of XML.

XML for XML’s sake
Several products and projects out there are using XML. By using, I mean that at some point in some process, the data is converted to XML, processed, and converted into something else. But the processes that use the XML data don’t necessarily require XML for any particular reason. In some cases, it’s simply an excuse to use XML data. In my opinion, this is not a wise design decision. If your product contains XML just for the sake of having XML, you should reevaluate your goals. Having “XML” stamped on the product brochure may look good, but having XML in the internal process probably doesn’t gain you anything and may even cause problems down the road, as XML standards and XML parser engines change.

The ability to interoperate with external systems has driven many products to an XML solution. Assuming that a workable XML solution has been designed and standardized, XML is the tool for the job. Because it provides extensibility and data standardization, an XML framework can be used to solve complex business integration scenarios. Examples of good solutions (despite the current market) include supply chain management (SCM) developments, such as Commerce One’s Common Business Library (CBL). With CBL, an XML framework provides a dictionary of XML documents that can be used to describe various pieces of data, as well as different processes.

That’s enough soapbox for one week. This discussion was designed to help you understand that XML really is a technical solution to technical problems. While you can find many ways to implement and use XML data, there are only a few that make use of and take advantage of the features XML provides.