Friday, June 29, 2007

XQuery API for Java, JSR 225, sadly missing external functions

The public review of of the XQuery interface for java is avaliable. The interface appears to be reasonable but it unfortunately has one major ommission: the ability to define external functions in Java. This is particularly anoying as this is a feature that I rely on day to day for my usage of XQuery in JDeveloper.

In my case I use XQuery to walk over WSDL and XSD documents to provide validation and contextual linking. In order to do this in synch with the user I need to be processing the in memory buffers rather than those in the file system. Obviously the standard "location" function doesn't know about these in memory copies. Instead I defined a new version of the location method which I implemented in java. My version can take multiple relative paths in order to make the code run more efficiently:

  (: Declare external functions  :)

  declare function xmlef_func:location($doc as item(), $location as xsd:string*) as node()* external;

This I can quite happily implement using some internal classes that I have access to in the Oracle internal implementation of the xquery api. I am told that most JSR 225 implementations will provide some extension mechanism for defining external functions; but that it wont be part of the standard. This of course will make it real hard to make portable code. It is also personally quite supprising because the XPath API already included in java does provide a mechanism for defining external functions.

Of course there might well be time constraints that I am not aware of; but it would seem a shame for the standard to not define an interface to this most useful of extension mechanisms. It would seem like the main focus for the JSR 225 expert group has been for XQuery to be used an a public API for querying data sources such as database connections. This is a real shame for me personally as I can get a lot of mileage out of XQuery for common XML processing actions. (And it is boon for those like me who find XSL harder to read back)

Having said that I wouldn't let this put you off using XQuery with Java, personally I find it by far much easier to write and read than XSL. There is always something to be said about using a different language notation when you are doing someting quiet different. With XQuery it is always immediately obvious what is XML and what is program construct which can really help with readibility.

Thursday, June 28, 2007

Moving Day

Looks like it is time to move from the very comfortable orablogs onto something a bit more modern. I would like to thank Brian a lot for hosting my blog over the years. He tells me that due to HD issue that I cannot update my blog there so there will be no redirects for the moment; but he hopes to fix this in due course.

Well then, back to work I think.