The Artima Developer Community
Interviews | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

The Human Side of XML
A Conversation with Elliotte Rusty Harold, Part VIII
by Bill Venners
September 8, 2003

Page 1 of 3  >>


Elliotte Rusty Harold talks with Bill Venners about the readability of XML documents and the code that processes them.

Elliotte Rusty Harold is a prolific author of numerous books about Java and XML, and creator of the popular Java website Cafe au Lait and XML website Cafe con Leche. He contributed to the development of JDOM, a popular XML processing API for Java. His most recent book, Processing XML with Java, shows how to parse, manipulate, and generate XML from Java applications using several XML APIs, including SAX, DOM, and JDOM.

At a meeting of the New York XML SIG in September, 2002, Harold unveiled an XML processing API of his own design: the XOM (XML Object Model) API. On Cafe au Lait and Cafe con Leche, Harold described XOM like this:

Like DOM, JDOM, dom4j, and ElectricXML, XOM is a read/write API that represents XML documents as trees of nodes. Where XOM diverges from these models is that it strives for absolute correctness and maximum simplicity. XOM is based on more than two years' experience with JDOM development, as well as the last year's effort writing Processing XML with Java. While documenting the various APIs I found lots of things to like and not like about all the APIs, and XOM is my effort to synthesize the best features of the existing APIs while eliminating the worst.

In this interview, which is being published in multiple installments, Elliotte Rusty Harold discusses the strengths and weaknesses of the various XML processing APIs for Java, the design problems with existing APIs, and the design philosophy behind XOM.

Parsing XML into XOM Subclasses

Bill Venners: I would like to ask you about readability of XML and code that processes XML. I have used both JDOM and JAXB to process XML in Java. One aspect of JAXB that I really liked was that it allowed me to represent my parsed documents in classes that map to the concepts of my document's schema. With JDOM, as with XOM, the classes map to the general concepts of XML documents, not to specific concepts of the particular schema. In your talk to the New York XML SIG you said something that I believe may concern parsing XML documents into classes that more closely model schemas. You said, "Factories can be used to build subclasses during parsing." What did you mean by that?

Elliotte Rusty Harold: Allowing subclasses to be built during parsing is another trick I learned from JDOM. I did not invent this myself. Even though I didn't copy much code from JDOM, I did copy lots of ideas, and that's one of them.

When XOM's Builder object, the parser in essence, reads an XML document, it does not call the constructors directly for the Element, Attribute, or Text classes. XOM is a class-based, not an interface-based, API, so those classes do have public constructors. But rather than calling those constructors directly, the Builder calls a factory that then calls the constructors.

This approach allows you to substitute a different factory on top of the parser. For example, if you substitute an XHTML factory, it can look at the data and say, "OK. We're being asked to create an element, and the name of the element is table. Therefore, I'm going to return my special TableElement object, rather than a generic XOM Element object."

Bill Venners: And TableElement extends Element.

Elliotte Rusty Harold: Right. It allows you to plug in your own subclass hierarchy.

Page 1 of 3  >>

Interviews | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use