Why XML?
This week's XML tip is not a conventional technical tip. Instead, I'd like
to focus on more of the "why" rather than the "how" of XML. Keep reading to
find out some good reasons to use XML and some better reasons not to use
it.
Feature-oriented "productization" and marketing
Sometimes a software project will have very definite specifications and
features that are needed to make the product both functional and usable..
Unfortunately (for the technically inclined), there's also 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. So, to help with the burden of
selling, marketing and sales departments often use industry buzzwords when
describing their products in order to both convince the client that the
product is "new and exciting" and hopefully help close the sale.
Unfortunately, XML has become a clich�, 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. 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
There are several products and projects out there that are using XML. By
using, I mean that at some point in some process, the data is converted to
XML, processed, and converted back into something else. The process that
used the XML data didn't necessarily require XML for any particular reason.
It was simply an excuse to use XML data. In my opinion, this is not a wise
design. If your product contains XML just for the sake of having XML, then
you should re-evaluate 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
the XML standards and XML parser engines change).
Interoperability
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 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.
Summary
That's enough soapbox for one week. These suggestions are 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.