XQuery as a general data processing language WAS: [xquery-talk] XQuery and Web 2.0

Peter Coppens pc.subscriptions at gmail.com
Mon Apr 28 22:34:51 PDT 2008

First -  Dana and others - thanks for asking the questions, listening  
and bringing up advice

> I would say: wrap the relational databases with a REST API (I send  
> you the SQL and the parameters, you give me back the result in XML),  
> and then from
> there on use XQuery. Or something along those lines.
> For most people switching from a relational database to an XML  
> database isn't an option, for a variety
> of reasons, but wrapping and hiding it is OK.
I agree....(I actually could and might try to use an XML database some  
day but)  it does seem the wrong approach as the RDBMS is fine for the  
persistent data the app needs to deal with.

> Or use products like BEA's Liquid Data that help you interact with a  
> relational database through XQuery
> if you don't want to do it by hand.

Yes....I prefer the XQuery implementation to figure out how to  
optimize joins etc in this context. I currently use DataDirect XQuery  
when integrating with 'raw' RDBMS data. It  (also) does a good job in  
this area.
> You said that there are several reasons of why you cannot use XQuery  
> in your daily job. In addition of
> relational databases, what other reasons ?

I guess I am just trying to figure out how a more traditional order  
processing like web app (using in my case Servlet's/EJB3/JPA/TopLink)  
could leverage the XML processing capabilities of XQuery (mostly for  
processing its input and output messages)
With what I have been able to come up with, the development overhead  
is bigger than I like it to be.

> Anything we can fix ?

THere might not be anything to fix in XQuery as such (except for the  
things that are ongoing like updates), but easier integration with the  
OO programming model might help.

I still feel that something *like* LINQ where (XQuery like)  
expressions can be executed that 'seamlessly' consume and/or create  
XML, relational and OO data would be ideal, but perhaps I am  
overlooking a bunch of other issues and/or perhaps such a thing is  
technically just not feasible.

More information about the talk mailing list