The Advantages of XML Data

The Advantages of XML Data
In many of the other chapters in this book, the lists of the advantages and disadvantages of XML are close to even; for sharing data, however, XML is a much more obvious choice. Of course, there are disadvantages that will rule out XML for certain projects, but in most cases, XML's advantages far outweigh the disadvantages, because there really is no general, portable alternative to XML for exchanging data with complex structure.

Behind the scenes, many companies are already using XML for internal data sharing, but despite its value, XML data itself is no longer a hot topic. Although the vendors continue to add support for XML in databases and other applications, the spotlight has moved on to XML networking (Chapter 5) and, especially, Web Services. However, even XML networking is still, at heart, using XML for data: Nearly all the networking specifications are simply combinations of XML data with a network transport layer, such as HyperText Transfer Protocol [HTTP].

XML brings clear and persuasive advantages for data exchange in five areas:

Platform and storage independence

Self-documentation

Reusability

Verification

Archiving and auditing

4.1.1. Platform and Storage Independence
In the past, save files for PC-based databases, such as FoxPro, sometimes became a de facto interchange format, just as Microsoft Excel spreadsheet files are a de facto standard for exchanging simple tabular data. Spreadsheets and other data applications also support some more portable formats, such as comma-delimited text or the sequels to the old Data Interchange Format (DIF). None of the portable alternatives, however, is particularly good at exchanging complex structured data.

XML can model arbitrarily complex data structures and is not tied to a specific vendor or product. With XML and Unicode, there are no byte-order, line-end, or character-encoding problems moving from machine to machine or even from country to country or culture to culture. All major and many minor programming and scripting languages have good support for XML, as do most databases.

XML's independence, however, goes far beyond simply avoiding platform incompatibilities. As discussed in Section 4.3, XML can represent data in its logical format rather than its physical storage format. Whereas a relational database might divide information into a series of separate, cross-linked tables, using attributes for order, XML can pull everything into a single, ordered, logical document.

XML's abstraction encourages loosely coupled data interchange. It does not matter whether the data provider and the data consumer arrange their databases differently, with different tables linked in different ways, because that physical level is not fossilized in XML as it would be in a series of comma-delimited table dumps. This fact, perhaps, matters more than all the other portability issues.

4.1.2. Self-Documentation
For humans, although not for computers, XML documents are at least partly self-describing, as discussed at length in Section 7.1.2. It might seem inconsistent, at first, to suggest that human readability is an advantage, when this chapter has been emphasizing that XML data is intended for machines. However, in practice, people still have to implement the programs or scripts to work with XML. Because XML documents normally have human-readable names for elements and attributes, developers will find it easier to produce, process, transform, and, most important, debug XML input and output. Human-readable names also make it possible to automate the creation of forms and other human interfaces for data entry.

4.1.3. Reusability
This advantage is related to storage independence (see Section 4.1.1). Well-designed XML data is almost always loosely coupled; it does not slavishly follow the structure of a spreadsheet, a set of database tables, or any other source but rather reorders the information into an abstract, logical presentation. Therefore, XML data is not limited to a single purpose. Data exported from a database can be read into another database, of course, but can also be edited, displayed, analyzed for statistical patterns, transformed, searched and queried, or even published to a Web page or print. The original data provider does not have to be able to anticipate all the uses people might have for XML data. Once the information is in XML format, XML tools and utilities will simply be able to work with it any way the recipient desires.

4.1.4. Verification
Developers often spend a lot of their time developing and testing code for data validation. With XML data, it is possible to do basic structural validation and, in some cases, data-type validation (see Section 4.5.3), using schema languages with off-the-shelf software tools and libraries. Writing an XML schema or DTD is a specialized skill, but it can sometimes be much easier and more robust than writing custom code to perform the same structural checks.

XML data allows verification in other ways as well. Because XML is plaintext, people can easily examine it for problems that automated tests might have missed, the same way that people can examine text-based Internet protocols, such as HTTP, SMTP, or Post Office Protocol v. 3 (POP3), manually for verification and debugging. And, like any text file, XML is relatively simple to sign digitally.

4.1.5. Archiving and Auditing
XML data consists of files, not bits on the wirelike a networking protocolor application-specific binary datalike a spreadsheet file. Because XML is not tied to an application that may no longer exist in a few years, XML data will still be useful in an archive 50 or 100 years from now; because it can be saved to disk, every transaction can be archived and audited, something that is difficult with protocols.

These points are especially important for companies or other organizations that face complex legal and reporting requirements. A saved XML transaction, like a saved e-mail, provides an ongoing record of what was happening in a company at a specific time. In case of a security breach, people can go back and review not only logs but also past transactions to track down the problem.