Processing Xml With Java - A Guide To Sax, Dom, Jdom, Jaxp, And Trax

Preface

One night five developers, all of whom wore very thick glasses and had recently been hired by Elephants, Inc., the world's largest purveyor of elephants and elephant supplies, were familiarizing themselves with the company's order processing system when they stumbled into a directory full of XML documents on the main server. "What's this?" the team leader asked excitedly. None of them had ever heard of XML before, so they decided to split up the files among them and try to figure out just what this strange and wondrous new technology was.

The first developer, who specialized in optimizing Oracle databases, printed out a stack of FMPXMLRESULT documents generated by the FileMaker Pro database where all the orders were stored, and began poring over them. "So this is XML! Why, it's nothing novel. As anyone can see who's able, an XML document is nothing but a table!"

"What do you mean, a table?" replied the second developer, well versed in object-oriented theory and occupied with a collection of XMI documents that encoded UML diagrams for the system. "Even a Visual Basic programmer could see that XML documents aren't tables. Duplicates aren't allowed in a table relation, unless this is truly some strange mutation. Classes and objects are what these documents are. Indeed, it should be obvious on the very first pass. An XML document is an object, and a DTD is a class."

"Objects? A strange kind of object, indeed!" said the third developer, a web designer of some renown, who had loaded the XHTML user documentation for the order processing system into Mozilla."I don't see any types at all. If you think this is an object, then it's your software I refuse to install. But with all those stylesheets there, it should be clear to anyone not sedated that XML is just HTML updated!"

"HTML? You must be joking" said the fourth, a computer science professor on sabbatical from MIT, who was engrossed in an XSLT stylesheet that validated all of the other documents against a Schematron schema. "Look at the clean nesting of hierarchical structures, each tag matching its partner as it should. I've never seen HTML that looks this good. What we have here is S-expressions, which is certainly nothing new. Babbage invented this back in 1882!"

"S-expressions?" queried the technical writer, who was occupied with documentation for the project, written in DocBook. "Maybe that means something to those in your learned profession. But to me, this looks just like a FrameMaker MIF file. However, locating the GUI does seem to be taking me a while."

And so they argued into the night, none of them willing to give an inch, all of them presenting still more examples to prove their points, but none bothering to look at the others' examples. Indeed, they're probably still arguing today. You can even hear their shouts from time to time on xml-dev. Their mistake, of course, was in trying to force XML into the patterns of technologies they were already familiar with rather than taking it on its own terms. XML can store data, but it is not a database. XML can serialize objects, but an XML document is not an object. Web pages can be written in XML, but XML is not HTML. Functional (and other) programming languages can be written in XML, but XML is not a programming language. Books are written in XML, but that doesn't make XML desktop publishing software.

XML is something truly new that has not been seen before in the world of computing. There have been precursors to it, and there are always fanatics who insist on seeing XML through database (or object, or functional, or S-expression) colored glasses. But XML is none of these things. It is something genuinely unique and new in the world of computing; and it's possible to understand it only when you're willing to accept it on its own terms, rather than forcing it into yesterday's pigeonholes.

There are a lot of tools, APIs, and applications in the world that pretend XML is something more familiar to developers—that it's just a funny kind of database, or just like an object, or just like remote procedure calls. These APIs are occasionally useful in very restricted and predictable environments; however, they are not suitable for processing XML in its most general format. They work well in their limited domains, but they fail when presented with XML that steps outside the artificial boundaries they've defined. XML was designed to be extensible, but sadly many of the tools designed for XML aren't nearly as extensible as XML itself.

This book is going to show you how to handle XML in its full generality. It pulls no punches. It does not pretend that XML is anything except XML, and it shows you how to design your programs so that they handle real XML in all its messiness: valid and invalid, mixed and unmixed, typed and untyped, and both all and none of these at the same time. To that end, this book focuses on APIs that don't try to hide the XML. In particular, there are three major Java APIs that correctly model XML, as opposed to modeling a particular class of XML documents or some narrow subset of XML. These are

• SAX, the Simple API for XML

• DOM, the Document Object Model

• JDOM, a Java native API

These APIs are the core of this book. In addition, I cover a number of preliminaries and supplements to the basic APIs, including

• XML syntax

• DTDs, schemas, and validity

• XPath

• XSLT and the TrAX API

• JAXP, a combination of SAX, DOM, and TrAX with a few factory classes

And, since we're going to need a few examples of XML applications to demonstrate the APIs, I also cover XML-RPC, SOAP, and RSS in some detail. However, the techniques this book teaches are hardly limited to those three applications.