Re: [xml-dev] JDBC in an XQuery world (?)

[Michael Sokolov <sokolov@ifactory.com>]

On 10/2/2011 1:02 PM, John Cowan wrote:
> David Lee scripsit:
>
>> This is one way of looking at it and perhaps the most fruitful.  But
>> I disagree with the premise that jdbc MUST use SQL as the query
>> language.  The difference between vendor's "SQL" is so vast they might
>> as well be different languages.  So why not allow pure xquery as the
>> JDBC query string?
> Well, if you want Hibernate to pretty much work out of the box, you need
> SQL.  You can't reasonably expect the Hibernate folks to add XQuery as
> one of their SQL dialects.
I still think it would be better to dump JDBC and just aim at the 
Hibernate users directly, but that may just be the world I live in at 
the moment.
>> As for the results .. Xquery returns xdm not XML so there needs to be
>> a mapping of xdm to ResultSet interface.
> True.  But you also need an input mapping of SQL concepts like tables,
> columns, and rows.
OK - I'll bite, mix metaphors, throw up a straw man and duck the tomatoes:

let's map "xml root element name" to "table" and "document" to "row"

"xpath expression" maps pretty naturally to "sql expression"

This might be enough for selects, but I guess for inserts you'd have to 
define column mappings.

These would probably have to be drawn from some subset of all xpath 
expressions like forward steps only, no function calls, something like 
that - I think MarkLogic searchable xpath expression is something like 
this).  You would have to introduce a new kind of schema for defining 
these mappings.