Thanks I remember studying those .. It might solve the data model mismatch issue, But as you say these are all on top of an RDBMS backend. What I'm thinking of is jdbc on top of MarkLogic/exists/BaseX/Saxon
But using the iso Spec for standardizing the data model issues could be benificial thanks Sent from my iPad (excuse the terseness) David A Lee [email protected] On Oct 2, 2011, at 3:30 AM, Peter Coppens <[email protected]> wrote: > David > > You might want to look into SQL/XML, ISO/IEC 9075-14:2008 - Information > technology -- Database languages -- SQL -- Part 14: XML-Related > Specifications (SQL/XML) > > Seems XMLTABLE and XMLQUERY construct and the associated datamodel mappings > might be of help to you. > > Don't know if there are implementations on top of an XML database (not sure > that would make sense neither), but I do know that some of the RDBMS vendors > have implemented this specification. > > Hth > > Peter > > On 02 Oct 2011, at 01:57, David Lee wrote: > >> From 'the beginning' there has been a lot of talk (and some actual >> work/products) which interface XQuery to a relational back end. >> A good deal of the design of XQuery (from my thousand-meter high view) was >> designed so it could map to a relational model or at least a relational >> database. >> There are papers, talks, and products which do this to varying degrees of >> success. >> >> But what about the other way? What if I have (or want) an XQuery database >> (or would you call that a XML database with an XQuery interface ...?) and >> expose it to relational-minded clients ? There's a huge existing ecosystem >> which understands the relational model, or the relational API's. Simply >> saying "oh just use this NEW API instead" doesn't make everyone happy. But >> if we could say 'Just use this new JDBC driver' ... hmmm >> >> Suppose we had a JDBC interface to XQuery/XML databases ? Sure it wouldn't >> be the best choice ... but then neither is using JDBC for Oracle or MySQL ... >> there are even JDBC drivers for CSV files .. . But its used ... a LOT ! >> Why ? Not because it's the best choice, but because its omnipresent and just >> works. Programmers learn one API and use it across the board. They then >> console themselves believing that they could switch vendors if they wanted >> (ya right) ... but its a nice comfortable illusion. For some reason few >> really care that you CANT switch from MySQL to Oracle by just swapping out >> the JDBC driver ... because the SQL itself is incompatible. But since the >> API is the same we live in this nice fantasy world. Unicorns and rainbow >> lollipops for everyone. >> Is that so bad ? Seems like it's not really ... >> >> >> I've been thinking .. Suppose we had a JDBC driver that could talk 'native' >> to an XQuery backend DB ? >> >> 1) What problems would it solve ? >> 2) What would it look like ? >> >> #1 ... problems. There's a lot of applications out there that can be given >> an JDBC driver and 'just work with it'. These might instantly become >> "XQuery Aware". >> Well maybe not .. but maybe they could do *something* given an JDBC >> connection to a XQuery database where before they could do nothing at all. >> >> #2 what would it look like ? I'm not talking about writing a SQL->XQuery >> mapping (although that's an interesting project in itself, maybe in V(n+1) ), >> but from an API layer ... JDBC just takes any old SQL string and executes it >> and returns a result set. The fact that MySQL and Oracle and DB2 and >> SQl/Server are entirely incompatible in SQL doesn't cause much problems as >> its 'just a string'. Suppose this new JDBC driver took XQuery as the "sql' >> string. What could it do ? >> The issues I think of are >> >> #A Binding of '?' variables. these translate neatly into XQuery external >> variables, but a simple case could simply not support them. I'm not sure if >> Connection.prepareStatement() *requires* support for "?" bindings ? I'm sure >> we could come up with some kind of convention to handle them. I do >> something similar in xmlsh where I prepend any XQuery within <[ xquery >> statement ]> with a set of 'declare variable $_n extern' ... which lets you >> use external variables implicitly without predeceasing them. Same concept >> could work so that JDBC's PreparedStatement.setInteger( field , value ) >> could work against an XQuery statement. >> >> #B Result sets. Here's the fun. What does XQuery return ? XDM. How to >> map XDM to a JDBC result set ? >> Would each item in the sequence be a row or column ? If a row then what is >> its type ? JDBC allows you to query the type of every column so that >> implies that each row's corresponding column must be the same type. Not >> true if XDM sequences are rows. Is this a requirement ? What if it just >> faked out the type of the first "row" ... what would break ? Maybe only >> apps that read the catalog and assume all rows have the same structure (1 >> column of type 'x' most likely 'string'). >> >> Or the result set could be a single row where each item is a column. >> Atomic XDM types map fairly well to JDBC types. XML types could be a kind >> of BLOB or VARCHAR ... >> >> Not sure where this is going :) ... but I am thinking surely this must have >> been thought of and implemented so far. >> But I haven't seen it. Anyone know of any work in this direction ? >> Anyone think of any good use cases ? >> I'm thinking this might be a way of leveraging XML Databases in an otherwise >> 'relational shop' ... and if taken up might encourage XML DB Vendors to put >> a bit more effort into supporting the things that relational DB's are >> actually good at ... Joins ... >> Maybe this might lead to a standard (or 'common') SQL -> XQuery mapping. >> >> >> Ideas ? Tomatoes ? >> >> -David >> >> >> ---------------------------------------- >> David A. Lee >> [email protected] >> http://www.xmlsh.org >> >> _______________________________________________ >> [email protected] >> http://x-query.com/mailman/listinfo/talk >
_______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
