GTXML Article

XML

XML is the format of the frontier, everything seems to be XML these days, from make scripts (ANT) to geospatial data (GML). A wonderful benifit of having XML around is this - it gets you out of writing a parser.

But there is a problem with this: what do the available parsers give you? SAX gives you a series of callbacks, DOM gives you a memory model of Nodes, JDOM is a little nicer in that it makes the Nodes follow Java conventions.

Something seems to be amiss - where are the Objects?

Objects

Their are a number of XML to Object technologies around, JAXB is the new kid on the block and worth considering. JAXB works by taking the description of your document (XMLSchema) and generating source code for Java Beans to represent the content.

JAXB also provides a marshalling system that will:

map the XMLSchema simple types over to Java primatives
map your document over to those generated Java Beans

Pretty fun stuff. What could possibly go wrong?

Well the answer is, as usual, geospatial data. For those new to the field geospatial data often has way more data then is considered sane. Six hundard page XMLSchema documents generated directly from UML models are something we see every month or so. The Geographic Markup Language (GML) standard is actually a XMLSchema document designed to be extended (not used directly) to model the specific information at hand.

Geotools XML Parsing

So what improvements, with respect to JAXB, can GeoTools offer:

handle large content (bigger then memory)
handle new content on the fly

The geotools parsing system has a few additional bindings you might expect:

XMLSchema simple types are supported
OGC Filter is supported
OGC GML2 (and soon GML3) are supported

This only makes sense, as we are working with a spatial toolkit. However here is the trick. The same facilities are available to you when mapping your own content.

Oh and one more thing ... the parse is "schema assisted".

Schema Assisted Parsing

What on earth does this mean? It means that the parser "knows" about the schema of your document and uses it to reduce the amount of code you have to write. XMLSchema is rather through, the same information required for "validation" is repurposed to get you out of writing as much code as possible.

Now JAXB also has a technique to avoid writing code, it did so by generating sourcecode from the XMLSchema. Here is where geotools is different - when extending a schema geotools will often be able to parse your documents directly (right out of the box), with no coding what so ever.

The Big Picture

In this diagram you can see we have marked some of the schema types as having bindings. This means that a class has been written that knows how to convert content of that type into a java object.

As you can see, right out of the box, the geootols parser would be able to completly parse a document and produce "Cyclist" objects. But if we choose we can provide a Binding for the photo type shown.

Example Binding

To give you an example of the amount of work involved in setting up a Binding we will parse photo into a Icon rather then a URI.

Some things to note about this example:

The binding is assoication with a normal java QName
A code generator is available for Binding classes
A javadocs with the schema fragment is included for reference

Did you notice? We can cast value to a URI because the framework has already put the schema to work for you. The type photo extends xs:url, allowing the framework to process the value into a URI for you.

The same trick is used to present attribute values as real java objects!

class Photo extends SimpleBinding {
   public QName getName(){
       return new QName( NAMESPACE, "photo" );
   }
   /**
    * Parse to Icon.
    * <xs:simpletype name="photo">
    *    <extention base="xs:anyUri"/>
    * </xs:simpletype>
    */
   public Object parse( Elemenet element, Object value ){
       URI uri = (URI) value;
       return new ImageIcon( uri.toURL() );
   }
}

Remember

Parsing is easy, if you use all the available information (including schema) to help you. When working with GeoTools we will try and do as much work for you as we possibly can.

Streaming!

capable of handling data larger then memory!
This is GIS - not a toy

Schema Assist!

if someone bothered to be specific with a schema, it just means less coding for you

Programmer Assist!

we are here to help, from code generators to parsing attributes
We want your coding to to be fill-in-the-blank easy.

For more details please contact Justin Deoliveira or Jody Garnett.