I agree with Peter here: SQL/XML is already a fairly complete solution.
For those of you not familiar with SQL/XML, it does a couple of things:
1) It defines a set of functions that allow you to return relational
data as XML. This is the relational => XML mapping.
2) It defines a primitive XML data type. That is, you can have a column
whose type is XML and store XML documents in that column.
3) XMLTABLE allows you to use XPath-like constructs to define what parts
of an XML document (either stored in an XML column or constructed on the
fly) correspond to a table. You then use SQL to query that "table." (See
Peter's example below.) This is the XML => relational mapping.
In the case of XML databases, a collection in the XML database would
correspond to an XML column in a relational database. This could be
queried via XMLTABLE (which maps the XML documents to relational tables)
and SQL (which queries those tables). (I can't remember whether
XMLTABLEs are updateable -- I suspect not -- so this doesn't address the
update side of the question.)
As a side note, it's misleading to think of "XQuery databases" here.
XQuery is, at most, an implementation detail. That is, the class of
drivers you are talking about would work with different XML data
sources: XML databases, XML documents in the file system, URLs that
return XML, etc.
How you implement such drivers depends on the data source and the amount
of work you want to do. For example, to implement such a driver over an
XML database that supports XQuery, you could map SQL to XQuery or you
could just use XPath to extract data from the database, construct tables
from that data, and use a lightweight SQL engine to further query that
data. (Not efficient, but easier to implement, and similar to what JDBC
drivers over CSV do today.)
-- Ron
P.S. For a list of products that already do this sort of thing, see:
http://www.rpbourret.com/xml/ProdsWrappers.htm
The URLs are all out of date, but the descriptions give a flavor of what
has already been done.
Peter Coppens wrote:
On 02 Oct 2011, at 20:42, John Cowan wrote:
Liam R E Quin scripsit:
What if I have (or want) an XQuery database
(or would you call that a XML database with an XQuery interface ...?)
SQL/XML I think describes enough of a mapping, no?
I don't think so. SQL/XML extends SQL to add XML as a new kind of primitive
SQL data type, like strings, numbers, and dates. What's needed here is a
way to do ordinary SQL operations over an XDM-based database.
It does do a bit more as far as I understood it, e.g. it also introduce a
"schredding" construct, XMLTABLE
Here is an example
(http://www.ibm.com/developerworks/data/library/techarticle/dm-0708nicola/)
SELECT X.*
FROM emp,
XMLTABLE ('$d/dept/employee' passing doc as "d"
COLUMNS
empID INTEGER PATH '@id',
firstname VARCHAR(20) PATH 'name/first',
lastname VARCHAR(25) PATH 'name/last') AS X
In this case the source is still a table with some XML in some column but I
guess making the step to some XML collection in some XML database is not that
big.
Peter
_______________________________________________
[email protected]
http://x-query.com/mailman/listinfo/talk
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3933 - Release Date: 10/02/11
_______________________________________________
[email protected]
http://x-query.com/mailman/listinfo/talk
