XOM API for Processing XML with Java

["Michael Kay" <mike AT saxonica.com>]

>   I was thinking about this yesterday when I noticed dom4j had a 
> function to generate a location path for any given node. I've seen 
> several people ask for this in various contexts, and I 
> thought I might 
> write a sample program that did this, though I wasn't going 
> to add it to 
> the core like dom4j did. However, that expression always returns a 
> node-set; and it's the only example of machine generated XPath I can 
> think of right now.

Actually, I think it's more likely to be an application that's interpreting
XPath expressions held in some file, rather than generating them from
scratch - though the interpreter may be doing some "assembly" work, e.g.
concatenating expression fragments.

I've seen quite a number of applications hold XPath expressions in a
user-defined data file to define business rules, formatting rules for a
report, or such like. For example to produce customised reports there may be
a general framework to output tables with one row for each element, and a
control file giving XPath expressions to be evaluated, one for each column,
and perhaps XPath expressions to define the sort keys for the rows. The idea
of course is that this control file can be edited by someone without Java
knowledge. I've seen this kind of thing very often in XSLT (where it
requires dyn:evaluate), but I can see it working just as well in Java. In
this scenario the results of the XPath expression would almost always be
strings or numbers.

Another similar example used a file of XPath expressions to define
conditions that should cause output values to be highlighted. Here the
expressions tended to be boolean expressions, e.g. @sales < 10. The reason
people want to do this computation in XPath rather than Java is that the
XPath is easier to change, it doesn't require the application to be
recompiled. (Incidentally, such an expression is likely to be evaluated many
times in each run of the application, against different context nodes, so
the ability to precompile expressions is also important for this scenario.)

Incidentally, I come across a lot of XSLT users who panic when I suggest
they should write some Java. They don't think of XSLT as programming...

Michael Kay
http://www.saxonica.com/