Extensible Markup Language (XML) is emerging as the format of choice for a variety of types of data, especially documents. With its ability to tag different fields, XML makes searching simpler and more dynamic, turning enterprise documents from recycling fodder into data mining gold. Because XML content is liberated from presentation format -- which independent style sheets specify -- XML enables the extensive reuse of material. This allows enterprises to turn the same content into press releases, white papers, brochures, presentations and Web pages. For enterprises trying to meld incompatible systems, XML can serve as a common transport technology for moving data around in a system-neutral format. In addition, XML can handle all kinds of data, including text, images and sound -- and is user-extensible to handle anything special.

Clearly, XML is coming into its own and seems destined to become the lingua franca of data online and off-line.

The problem until now has been how to manage the XML-tagged data. One promising solution is to use databases to store, retrieve and manipulate XML. The idea is to place the XML-tagged data in a framework where searching, analysis, updating and output can proceed in a more manageable, systematic and well-understood environment. Databases have the merit that users are familiar with them and their behavior, so taming XML with a database context seems natural.

However, there are XML databases and there are XML databases. Purists would contend that only databases that store XML in its native format deserve the label "XML database." Others contend that if you can store and retrieve XML from it, and it's a database, then it's an XML database, regardless of how the data is stored. We'll sidestep these religious battles and consider both types. If the XML isn't stored internally as XML, we'll call that an "XML-enabled database." If the XML is actually stored as XML internally, we'll call it a "native XML database."

There are a number of reasons to use existing database types, and existing database products, to store XML even if it isn't in its native form. First, ordinary relational and object-oriented databases are well known, while native XML databases are new. Second, as a result of familiarity with relational and object-oriented databases, users understand their behavior, especially with regard to performance. There is a reluctance to move to a native XML database whose characteristics -- especially scalability -- haven't been tested. Finally, relational and object-oriented databases are safe choices in the corporate mind. It's the old "nobody ever got fired for buying X" rationale. You don't necessarily want to bet the enterprise on a native XML database when you don't have to.

Luckily, you don't have to. There are XML-enabled databases that handle XML fine and that are based on

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine