Basic Standards

These are the basic standards you need to be familiar with. They come up in almost any discussion of XML.

SAX

The Simple API for XML was a product of collaboration on the XML-DEV mailing list rather than a product of the W3C. It's included here because it has the same "final" characteristics as a W3C recommendation.

You can think of SAX as a "serial access" protocol for XML that is ideal for stateless processing, where the handling of an element does not depend on any of the elements that came before. With a small memory footprint and fast execution speeds, this API is great for straight-through transformations of data into XML, or out of it. It is an event-driven protocol, because you register a handler with the parser that defines one callback method for elements, another for text, and one for comments (plus methods for errors and other XML components).

StAX

The Streaming API for XML is a Java "pull parsing" API. This API also acts like a "serial access" protocol, but its processing model is ideal for state dependent processing. With this API, you ask the parser to send you the next thing it has, and then decide what to do with what it gives you. For example, when you're in a heading element and you get text, you'll use one font size. But if you're in a normal paragraph and you get text, you'll use a different font size.

DOM

The Document Object Model protocol converts an XML document into a collection of objects in your program. You can then manipulate the object model in any way that makes sense. This mechanism is also known as the "random access" protocol, because you can visit any part of the data at any time. You can then modify the data, remove it, or insert new data.

JDOM and dom4j

Although the Document Object Model provides a lot of power for document-oriented processing, it doesn't provide much in the way of object-oriented simplification. Java developers who are processing more data-oriented structures--rather than books, articles, and other full-fledged documents--frequently find that object-oriented APIs such as JDOM and dom4j are easier to use and more suited to their needs.

Here are the important differences to understand when you choose between the two:

JDOM is a somewhat cleaner, smaller API. Where coding style is an important consideration, JDOM is a good choice.

JDOM is a Java Community Process (JCP) initiative. When completed, it will be an endorsed standard.

dom4j is a smaller, faster implementation that has been in wide use for a number of years.

dom4j is a factory-based implementation. That makes it easier to modify for complex, special-purpose applications. At the time of this writing, JDOM does not yet use a factory to instantiate an instance of the parser (although the standard appears to be headed in that direction). So, with JDOM, you always get the original parser. (That's fine for the majority of applications, but may not be appropriate if your application has special needs.)

DTD

The Document Type Definition specification is actually part of the XML specification rather than a separate entity. On the other hand, it is optional; you can write an XML document without it. And there are a number of schema standards proposals that offer more flexible alternatives. So the DTD is discussed here as though it were a separate specification.

A DTD specifies the kinds of tags that can be included in your XML document, along with the valid arrangements of those tags. You can use the DTD to make sure that you don't create an invalid XML structure. You can also use it to make sure that the XML structure you are reading (or that got sent over the Net) is indeed valid.

Unfortunately, it is difficult to specify a DTD for a complex document in such a way that it prevents all invalid combinations and allows all the valid ones. So constructing a DTD is something of an art. The DTD can exist at the front of the document, as part of the prolog. It can also exist as a separate entity, or it can be split between the document prolog and one or more additional entities.

However, although the DTD mechanism was the first method defined for specifying valid document structure, it was not the last. Several newer schema specifications have been devised. You'll learn about those momentarily.

Namespaces

The namespace standard lets you write an XML document that uses two or more sets of XML tags in modular fashion. Suppose for example that you created an XML-based parts list that uses XML descriptions of parts supplied by other manufacturers (online!). The price data supplied by the subcomponents would be amounts you want to total up, whereas the price data for the structure as a whole would be something you want to display. The namespace specification defines mechanisms for qualifying the names so as to eliminate ambiguity. That lets you write programs that use information from other sources and do the right things with it.

XSL

The Extensible Stylesheet Language adds display and transformation capabilities to XML. The XML standard specifies how to identify data, rather than how to display it. HTML, on the other hand, tells how things should be displayed without identifying what they are. Among other purposes, XSL bridges the gap between the two.

The XSL standard has two parts: XSLT (the transformation standard, described next) and XSL-FO (the part that covers formatting objects). XSL-FO lets specify complex formatting for a variety of publications.

XSLT (+XPath)

The Extensible Stylesheet Language Transformations standard is essentially a translation mechanism that lets you convert XML data into other forms--for example, into HTML. Different XSL transforms then let you use the same XML data in a variety of ways. (The XPath standard is an addressing mechanism that you use when constructing transformation instructions. You use it to specify the parts of the XML structure you want to transform.)