XOM API for Processing XML with Java

[Elliotte Harold <elharo AT metalab.unc.edu>]

Michael Kay wrote:

> I think that retrieving a list of 20000 nodes into your application, when
> all you wanted to know was how many there were, is the wrong thing. If the
> XPath engine is accessing a database then it's catastrophically wrong: you
> should push as much of the processing to the database as possible.

In this case, the nodes already exist. All that's created is the list to 
hold them, not the nodes themselves. Not trivial, but not a big deal 
either. I agree that trade-offs may shift for a database using XQuery 
and XPath 2, bit that's not the case here. We're only talking about 
XPath 1 operating against XOM's native storage, nothing fancier.

> But I have to admit, I've been finding that writing real applications by
> calling out from Java to XPath is very tedious and I'm not sure it's the
> right way to go. I've been finding it much easier to write the bulk of the
> application in XSLT and call out where necessary to Java.

For that to be really attractive to me, I think extension function and 
element mechanisms would have to improve dramatically. I suspect they 
could improve. I just haven't been impressed by the ones I've seen to date.

Ultimately it may depend on whether your problem is more XML with a 
little Java thrown in or more Java with a little XML thrown in. 
Publishing a book is a very different operation than running finite 
difference calculations data that just happens to be stored in XML. Is 
the XML core to the problem or is it just a convenient serialization and 
exchange format? If it's core, XSLT works very nicely. If it's not, 
you'd be better off with Java as the main driver. I wouldn't try to 
write OpenOffice in XSLT, for example.

--
Elliotte Rusty Harold  elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim