The upcoming release of Java version 1.5 is set to change the way we use XML in Java code. A preview is available in an early release of JAXB, the Java API for XML Binding. What this means is that you no longer have to think in terms of using SAX API or DOM API directly in your code. No more running with the parser, or tearing your hair over element nodes, text nodes and the tree hierarchy.

What exactly are the issues involved in the binding process? It is basically a conversion process from structured XML data to Java objects, which happens to be the subject of this article.

Take this piece of XML data for example.

<?xml version="1.0">
  <table>
    <tr>
     <td>First Row First Column</td>
     <td>First Row Second Column</td>
    </tr>
    <tr>
     <td>Second Row First Column</td>
     <td>Second Row Second Column</td>    
    </tr>
   </table>

Yes! Roll out your own html. 

Now to convert this piece of structured data to Java code is pretty straightforward. We use a simple mapping rule like so:

1. Map root element to a class
2. Map top level elements to methods, loop for count
3. Store values in instance variables, loop for count

Using this simple (ouch! simplistic) technique, we have the Java binding as shown below.

public class table {
	
  String td[] = null;

  public int gettrcount() {
    int n=0;
   // loop through the data and count the top level elements (using SAX or DOM as you prefer)
   // increment n for each top level element
   return n;
 }
	
  // for each top level element, loop through the data and store in td array
  public String[][] gettdvalues() {
    int tdcount = 0;
    String[][] data = null;
    // loop through each tr count and extract data
    for(int i=0; i<trcount; i++) {
      for(int j=0; j<tdcount; j++) {
       // allocate memory to data variable as you go along and fill with td values
      }
    }
    return data;
  }
}

How is the mapping process? Interesting, but not satisfactory. First, it expects that you know how the data is packaged in XML. Second, if the data is to be represented in types other than Strings, you need to know that upfront, before you start working on the data. Third, if you add elements and attributes arbitrarily, you will get into serious trouble, for how do you let the convertor program know that?

As we said earlier, we have taken a simplistic approach. Of course, you are going to use a DTD for your XML data. Good. Your convertor works on the DTD instead, and provides you the class bindings that you need. That is, as long as the XML data file validates against that DTD! So long so good.

Let us write a DTD for our data file, and see if the convertor code stands upto it. The DTD snippet can be directly embedded in the XML file.

<!DOCTYPE table [
<!ELEMENT table (tr+)>
<!ELEMENT tr (td+)>
<!ELEMENT td (#PCDATA)>
]>

To work on text such as this you got to have to work hard, I mean really hard. And if you have to make your convertor a generic tool, you must implement the entire set of DTD notations! Now that is quite an arduous task. If you have to work with an XML document, you could use the existing parsers and write a convertor program that serves your purpose. But DTDs are not XML documents.

Enter XML Schema. An XML schema serves the same purpose as a DTD and provides a rich set of features that are not possible in a DTD. A DTD treats all data values as strings. A schema on the other hand allows you to provide language bindings like data types, and database like constraints applied to data values. For instance, you may want "123" to be treated as int and not as a String, or limit an element to a maximum number of occurances. What's more. A schema is an XML document that you can directly start working with your favorite XML parser, DOM or SAX.

The XML to Java binding process is fairly complex, and it is best left to the experts to do all the hard work. What is interesting to the developer is the possibilities that open up with API like the JAXB that does this process so well. Most modern databases like MS SQL server 2000 now ship with XML capability built into it. You get the result set in XML format, and perform all the DML operations via XML. Cool. Now we can use an extended JAXB to convert that into Java classes? Too early, perhaps! But it is a possibility that I cannot ignore. It should be possible to move data from a database to Java objects via XML. The future API may well create an abstraction involving the JDBC code and XML-to-Java binding process, so that the developer is completely shielded from the underlying complexity that is routine and error prone.

The JAXB API release is a welcome feature to the Java developer repertoire. Check out: http://java.sun.com/xml in case you are an early adopter like myself.