JDOM and TRaX

JDOM

Brett McLaughlin announced the Open Source JDOM API to the Xerces-Java mailing list last week, describing it as an alternative to the W3C DOM API:

JDOM is an open source API for easily and efficiently reading and writing XML data. It's a replacement for the ridiculously complex DOM and SAX APIs. Unlike DOM and SAX, JDOM is optimized for the Java programmer; it uses standard Java programming idioms and takes advantage of Java language features.

Several developers were quick to voice their support for the API, describing it as both simpler than the DOM and closer to the Java XML API they were expecting. Scott Boag believes there is room for both APIs:

It's certainly useful for many things, and a great contribution! Rather than being competitive with the DOM, I think it may be simply an alternative tree structure for those needing the particular benefits it provides.

Jason Hunter, who co-designed the API with Brett McLaughlin, described their goal as being to produce an API that is lightweight and fast, but not necessarily fully-featured:

The goal of JDOM is to solve 80% (or more) of a Java programmer's XML problems with 20% (or less) of the traditional effort. We also need to be lightweight and fast. This means that some end cases will not be supported, because to support them would overly complicate learning the API, overly complicate using the API, require too much memory overhead, and/or require too much CPU work.

JDOM is based around a tree interface similar to the DOM, but does not make use of the W3C DOM interfaces. However, the API does offer the ability to interoperate with the SAX and DOM APIs, which can be used as both inputs and outputs.

McLaughlin stressed the differences between JDOM and the W3C DOM:

JDOM is an alternative to DOM and SAX. It provides a fast, Java-optimized method of reading, writing, and manipulating XML... DOM is trying to be a cross-platform, 100% accurate representation of an XML document. We don't believe that in most cases, Java developers need that. They want an intuitive, usable means of accessing XML data.

Arnaud Le Hors, a little annoyed by McLaughlin's reference to "the ridiculously complex DOM," agreed that the DOM API was not perfect, but claimed that

... nobody could have done better with the same constraints.

Michael Champion was of the same opinion, and believed that so-called "Common XML" might provide a better starting point:

... the DOM is too complex partly because XML is too complex yet underspecified, especially namespaces. My main suggestion is to simplify the API by constraining the XML that it handles, e.g. focus on Simon St. Laurent's "Common XML" guidelines rather than hoping to find a fully compliant but simple API for the general case.

Also commenting on the SML-DEV mailing list, Champion described the difficulty of producing a simpler XML API as being due to the "little nasties" in the XML specification.

However, comparing JDOM to the DOM is to some extent like comparing apples to oranges. The two projects have different design goals and therefore are going to produce different APIs. It does seem likely, however, that projects like Common XML could provide useful input.

Just as XML doesn't require monolithic global schemas, it also doesn't mandate single monolithic APIs that all programmers must use. The distinct advantage of JDOM is that the programmer has to know little about the complexities of XML markup to get started. This makes it attractive for Java developers who want a quick leg-up into the XML world.

Other comments concerning JDOM have focused on particular features. For example, at present it has only limited support for namespaces. However, following an interesting exchange with Elliotte Rusty Harold on the JDOM mailing list, Brett McLaughlin announced that full namespace support will be added.

It's definitely very early days for JDOM, but there's already a lot of activity on the mailing list, and there's a phase of rapid development. One to watch.

Making TRaX

Regular readers of this column will recall some recent discussion about the problems with XSLT extension functions (see "Unifying XSLT Extensions"). Following the publication of that article, the XSL Working Group made a formal announcement that highlighted their commitment to improving XSLT, and invited discussion from XSLT developers.

That invitation was clearly taken to heart, as this week saw the announcement of TRaX ("Transformations for XML"), a vendor neutral API that

... defines an interface for processing transformation instructions, performing tree transformations via a transformer, and sending the result to SAX handlers, and interfacing to a Serializer if needed. While this interface is modeled on the XSLT process, it should be generic enough to use with many types of transformations besides XSLT. TRaX uses and is dependent on SAX2. TRaX is a Java API right now, but it would be great to get a C++, COM, and Perl version as well.

TRaX is the result of collaboration by many XSLT processor developers and is thus likely to be adopted quite quickly. This will allow developers to produce XSLT-based applications that are not tied to particular XSLT implementations, circumventing one significant problem with the current state of affairs.

Given the invitation of the XSL Working Group, it's possible that TRaX could be an important input towards, if not the foundation for, future developments of XSLT. In any case, it has real potential to become a de facto standard just like SAX, and no doubt it'll be supported by the major XSLT processors very shortly.