XML document processing in Java using XPath and XSLT

The Extensible Markup Language (XML) is certainly one of the hottest technologies at the moment. While the concept of markup languages is not new, XML seems especially attractive to Java and Internet programmers. The Java API for XML Parsing (JAXP; see Resources), having recently been defined through the Java Community Process, promises to provide a common interface for accessing XML documents. The W3C has defined the so-called Document Object Model (DOM), which provides a standard interface for working with an XML document in a tree hierarchy, whereas the Simple API for XML (SAX) lets a program parse an XML document sequentially, based on an event handling model. Both of these standards (SAX being a de facto standard) complement the JAXP. Together, these three APIs provide sufficient support for dealing with XML documents in Java, and numerous books on the market describe their use.

Featured Resource

Presented by Zero Turnaround

Coding with JRebel: Java Forever Changed

With JRebel, developers get to see their code changes immediately, fine-tune their code with

Learn More

This article introduces a way to handle XML documents that goes beyond the standard Java APIs for manipulating XML. We'll see that in many cases XPath and XSLT provide simpler, more elegant ways of solving application problems. In some simple samples, we will compare a pure Java/XML solution with one that utilizes XPath and/or XSLT.

Both XSLT and XPath are part of the Extensible Stylesheet Language (XSL) specification (see Resources). XSL consists of three parts: the XSL language specification itself, XSL Transformations (XSLT), and XML Path Language (XPath). XSL is a language for transforming XML documents; it includes a definition -- Formatting Objects -- of how XML documents can be formatted for presentation. XSLT specifies a vocabulary for transforming one XML document into another. You can consider XSLT to be XSL minus Formatting Objects. The XPath language addresses specific parts of XML documents and is intended to be used from within an XSLT stylesheet.

For the purposes of this article, it is assumed that you are familiar with the basics of XML and XSLT, as well as the DOM APIs. (For information and tutorials on these topics, see Resources.)

Note: This article's code samples were compiled and tested with the Apache Xerces XML parser and the Apache Xalan XSL processor (see Resources).

The problem

Many articles and papers that deal with XML state that it is the perfect vehicle to accomplish a good design practice in Web programming: the Model-View-Controller pattern (MVC), or, in simpler terms, the separation of application data from presentation data. If the application data is formatted in XML, it can easily be bound -- typically in a servlet or Java ServerPage -- to, say, HTML templates by using an XSL stylesheet.

But XML can do much more than merely help with model-view separation for an application's frontend. We currently observe more and more widespread use of components (for example, components developed using the EJB standard) that can be used to assemble applications, thus enhancing developer productivity. Component reusability can be improved by formatting the data that components deal with in a standard way. Indeed, we can expect to see more and more published components that use XML to describe their interfaces.

Because XML-formatted data is language-neutral, it becomes usable in cases where the client of a given application service is not known, or when it must not have any dependencies on the server. For example, in B2B environments, it may not be acceptable for two parties to have dependencies on concrete Java object interfaces for their data exchange. New technologies like the Simple Object Access Protocol (SOAP) (see Resources) address these requirements.

All of these cases have one thing in common: data is stored in XML documents and needs to be manipulated by an application. For example, an application that uses various components from different vendors will most likely have to change the structure of the (XML) data to make it fit the need of the application or adhere to a given standard.

Code written using the Java APIs mentioned above would certainly do this. Moreover, there are more and more tools available with which you can turn an XML document into a JavaBean and vice versa, which makes it easier to handle the data from within a Java program. However, in many cases, the application, or at least a part of it, merely processes one or more XML documents as input and converts them into a different XML format as output. Using stylesheets in those cases is a viable alternative, as we will see later in this article.

Use XPath to locate nodes in an XML document

As stated above, the XPath language is used to locate certain parts of an XML document. As such, it's meant to be used by an XSLT stylesheet, but nothing keeps us from using it in our Java program in order to avoid lengthy iteration over a DOM element hierarchy. Indeed, we can let the XSLT/XPath processor do the work for us. Let's take a look at how this works.

Let us assume that we have an application scenario in which a source XML document is presented to the user (possibly after being processed by a stylesheet). The user makes updates to the data and, to save network bandwidth, sends only the updated records back to the application. The application looks for the XML fragment in the source document that needs to be updated and replaces it with the new data.

We will create a little sample that will help you understand the various options. For this example, we assume that the application deals with address records in an addressbook. A sample addressbook document looks like this:

<addressbook>
   <address>
      <addressee>John Smith</addressee>
      <streetaddress>250 18th Ave SE</streetaddress>
      <city>Rochester</city>
      <state>MN</state>
      <postalCode>55902</postalCode>
   </address>
   <address>
      <addressee>Bill Morris</addressee>
      <streetaddress>1234 Center Lane NW</streetaddress>
      <city>St. Paul</city>
      <state>MN</state>
      <postalCode>55123</postalCode>
</address>
</addressbook>

The application (possibly, though not necessarily, a servlet) keeps an instance of the addressbook in memory as a DOM Document object. When the user changes an address, the application's frontend sends it only the updated <address> element.

The <addressee> element is used to uniquely identify an address; it serves as the primary key. This would not make a lot of sense for a real application, but we do it here to keep things simple.

We now need to write some Java code that will help us identify the <address> element in the source tree that needs to be replaced with the updated element. The findAddress() method below shows how that can be accomplished. Please note that, to keep the sample short, we've left out the appropriate error handling.

public Node findAddress(String name, Document source) {
   Element root = source.getDocumentElement();
   NodeList nl = root.getChildNodes();
   // iterate over all address nodes and find the one that has the correct addressee
   for (int i=0;i<nl.getLength(); i++) {
      Node n = nl.item(i);
      if ((n.getNodeType() == Node.ELEMENT_NODE) && 
          (((Element)n).getTagName().equals("address"))) {
         // we have an address node, now we need to find the 
         // 'addressee' child
         Node addressee = ((Element)n).getElementsByTagName("addressee").item(0);
         // there is the addressee, now get the text node and compare
         Node child = addressee.getChildNodes().item(0);
         do {
            if ((child.getNodeType()==Node.TEXT_NODE) &&
                (((Text)child).getData().equals(name))) {             
               return n;
            }
            child = child.getNextSibling(); 
                  } while (child != null);
      }
   }
   return null;
}

The code above could most likely be optimized, but it is obvious that iterating over the DOM tree can be tedious and error prone. Now let's look at how the target node can be located by using a simple XPath statement. The statement could look like this:

//address[child::addressee[text() = 'Jim Smith']]

We can now rewrite our previous method. This time, we use the XPath statement to find the desired node:

public Node findAddress(String name, Document source) throws Exception {
   // need to recreate a few helper objects
   XMLParserLiaison xpathSupport = new XMLParserLiaisonDefault();
   XPathProcessor xpathParser = new XPathProcessorImpl(xpathSupport);
   PrefixResolver prefixResolver = new PrefixResolverDefault(source.getDocumentElement());
   // create the XPath and initialize it
   XPath xp = new XPath();
   String xpString = "//address[child::addressee[text() = '"+name+"']]";
   xpathParser.initXPath(xp, xpString, prefixResolver);
   // now execute the XPath select statement
   XObject list = xp.execute(xpathSupport, source.getDocumentElement(), prefixResolver);
   // return the resulting node
   return list.nodeset().item(0);
}

The above code may not look a lot better than the previous try, but most of this method's contents could be encapsulated in a helper class. The only part that changes over and over is the actual XPath expression and the target node.

This lets us create an XPathHelper class, which looks like this:

import org.w3c.dom.*;
import org.xml.sax.*;
import org.apache.xalan.xpath.*;
import org.apache.xalan.xpath.xml.*;
public class XPathHelper {
   XMLParserLiaison xpathSupport = null;
   XPathProcessor xpathParser = null;
   PrefixResolver prefixResolver = null;
   XPathHelper() {
      xpathSupport = new XMLParserLiaisonDefault();
      xpathParser = new XPathProcessorImpl(xpathSupport);
   }
   public NodeList processXPath(String xpath, Node target) thrws SAXException {
      prefixResolver = new PrefixResolverDefault(target);
      // create the XPath and initialize it
      XPath xp = new XPath();
      xpathParser.initXPath(xp, xpath, prefixResolver);
      // now execute the XPath select statement
      XObject list = xp.execute(xpathSupport, target, prefixResolver);
      // return the resulting node
      return list.nodeset();
   }
}

After creating the helper class, we can rewrite our finder method again, which is now very short:

public Node findAddress(String name, Document source) throws Exception {
   XPathHelper xpathHelper = new XPathHelper();
   NodeList nl = xpathHelper.processXPath(
        "//address[child::addressee[text() = '"+name+"']]", 
        source.getDocumentElement());
   return nl.item(0);
}

The helper class can now be used whenever a node or a set of nodes needs to be located in a given XML document. The actual XPath statement could even be loaded from an external source, so that changes could be made on the fly if the source document structure changes. In this case, no recompile is necessary.

Process XML documents with XSL stylesheets

In some cases, it makes sense to outsource the entire handling of an XML document to an external XSL stylesheet, a process in some respects similar to the use of XPath as described in the previous section. With XSL stylesheets, you can create an output document by selecting nodes from the input document and merging their content with stylesheet content, based on pattern rules.

If an application changes the structure and content of an XML document and producing a new document, it may be better and easier to use a stylesheet to handle the work rather than writing a Java program that does the same job. The stylesheet is most likely stored in an external file, allowing you to change it on the fly, without the need to recompile.

For example, we could accomplish the processing for the addressbook sample by creating a stylesheet that merges the cached version of the addressbook with the updated one, thus creating a new document with the updates in it.

Here is a sample of such a stylesheet:

<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
   <xsl:output method="xml"/>
<xsl:variable name="doc-file">http://mymachine.com/changed.xml</xsl:variable>
<!-- copy everything that has no other pattern defined -->
<xsl:template match="* | @*">
   <xsl:copy><xsl:copy-of select="@*"/><xsl:apply-templates/></xsl:copy>
</xsl:template>
<!-- check for every <address> element if an updated one exists -->
<xsl:template match="//address">
   <xsl:param name="addresseeName">
      <xsl:value-of select="addressee"/>
   </xsl:param>
   <xsl:choose>
      <xsl:when test="document($doc-file)//addressee[text()=$addresseeName]">
         <xsl:copy-of select="document($doc-file)//address[child::addressee[text()=$addresseeName]]"/>
      </xsl:when>
      <xsl:otherwise>
         <xsl:apply-templates/>
      </xsl:otherwise>
   </xsl:choose>
</xsl:template>
</xsl:stylesheet>

Note that the above stylesheet takes the updated data out of a file called changed.xml. A real application would obviously not want to store the changed data in a file before processing it. One solution is to add a special attribute to the <address> element, indicating whether or not it has been updated. Then the application could simply append the updated data to the source document and define a different stylesheet that detects updated records and replaces the outdated ones.

All the application has to do now is create an XSLTProcessor object and let it do the work:

import org.apache.xalan.xslt.*;
   ...
   XSLTProcessor processor = XSLTProcessorFactory.getProcessor();
   processor.process(new XSLTInputSource(sourceDoc.getDocumentElement(),
                     new XSLTInputsource("http://mymachine.com/updateAddress.xsl"),
                     new XSLTResultTarget(newDoc.getDocumentElement());
   sourceDoc = newDoc;
   ...

Conclusion

To many of us Java programmers, XML is a relatively new technology that we need to master. This article shows that the manual parsing and processing of an XML document is only one option, and that we may be able to use of XPath expressions and XSL stylesheets to avoid a lot of parsing and iterating, thus reducing the amount of code that we need to write. Moreover, under this system the information about how the data is processed is stored externally and can be changed without recompiling the application. The mechanisms described here can be used for the creation of presentation data for a Web application, but can also be applied in all cases in which XML data needs to be processed.

Learn more about this topic

• Recent XML articles in JavaWorld

• "Mapping XML to Java, Part 1," Robert Hustead (JavaWorld, August 4, 2000) explains how to use SAX to map XML documents to Java objects
  http://www.javaworld.com/javaworld/jw-08-2000/jw-0804-sax.html
• "XSL Gives Your XML Some Style," Michael Ball (JavaWorld, June 30, 2000) explains how XSL stylesheets can help with you programming
  http://www.javaworld.com/javaworld/jw-06-2000/jw-0630-xsl.html
• "Easy Java/XML Integration, Part 1," Jason Hunter and Brett McLaughlin (JavaWorld, May 18, 2000) introduces the new open source JDOM API for manipulating XML from within Java
  http://www.javaworld.com/javaworld/jw-05-2000/jw-0518-jdom.html
• "Programming XML in Java, Part 1," Mark Johnson (JavaWorld, March 2000) looks at how to use SAX to process XML documents in Java
  http://www.javaworld.com/javaworld/jw-03-2000/jw-03-xmlsax.html

• XML help

• JavaWorld's XML & Java discussion, moderated by Mark Johnson
  http://forums.itworld.com/webx?14@@.ee6b78f/60!skip=

• Other valuable XML-related resources

• Sun's Java API for XML Parsing (JAXP) page
  http://java.sun.com/xml/docs/api/
• The DOM API from the W3C
  http://www.w3.org/DOM/
• For good XML tutorials, visit the XML Zone of IBM's developerWorks
  http://www.ibm.com/developer/xml/
• More information on the Apache Xerces XML parser and the Apache Xalan XSL processor
  http://xml.apache.org
• More on the Simple Object Access Protocol (SOAP)
  http://www.ibm.com/software/developer/library/soap/soapv11.html
• For more on XSLT, see "What is XSLT" by G. Ken Holman from XML.com
  http://www.xml.com/pub/2000/08/holman/