W3C home > Mailing lists > Public > www-ql@w3.org > January to March 2003

Re: XQuery and relational databases...

From: Nitin Mangtani <nitinm@bea.com>
Date: Thu, 06 Mar 2003 21:03:04 -0800
Message-Id: <5.0.0.25.2.20030306205906.0375f4e8@sj-mail-01.beasys.com>
To: Jim Melton <jim.melton@acm.org>, Michael Burbidge <mburbidg@adobe.com>
Cc: www-ql@w3.org

Jim,

   Sorry for jumping on this tread late, why  "Group By" did not make into 
XQuery spec. I understand one can use combination of distinct and aggregate 
function to simulate a Group  By. But having a direct Group By makes life 
much easier for everyone (Customers, Vendors, you? and me;) ).

Regards,
Nitin Mangtani

At 11:29 AM 2/28/2003 -0700, Jim Melton wrote:

>Michael,
>
>I will not pretend to give an *official* Query WG response, so please 
>recognize that this note contains only my perception of the reasons.
>
>One of several major goals adopted when XQuery was designed was that it be 
>able to deal with queries on relational-like data.  Several major vendors 
>of XML systems and of relational systems explicitly want to be able to use 
>XQuery to query relational data that is "published" in an XML form out of 
>a relational database.
>
>However, I don't think that this was the primary motivation for the 
>creation of the FLWOR expression.  One very important attribute of SQL is 
>that it is primarily declarative in nature, not procedural.  By that, I 
>mean that SQL allows a user to specify what characteristics the desired 
>results have, but not the algorithms by which those results are 
>obtained.  That attribute is extremely important in several ways, but most 
>importantly in allowing query optimizers flexibility in putting together 
>"query plans" that operate specific queries differently in different 
>environments.  XQuery's design is also based on the 
>declarative-instead-of-procedural-language philosophy, specifically for 
>the same reasons that SQL was based on that philosophy.
>
>That characteristic by itself is not enough to determine whether or not 
>FLWOR expressions can be translated to SQL or SQL to FLWOR 
>expressions.  However, I have it on extremely good authority ;^} that it 
>is eminently feasible to translate a great fraction, possibly 100%, of 
>XQuery expressions into SQL.  Whether or not the reverse translation is 
>feasible, I don't have concrete information.  However, it would surprise 
>me if it were not possible to do so in some large percentage of cases.
>
>And, yes, you may confidently expect that relational database vendors will 
>implement XQuery processors that directly integrate with their 
>databases.  Whether this is done "in an efficient manner" will certainly 
>be in the eye of the beholder.  Some will undoubtedly put their XQuery 
>processors deeply embedded into their relational engines, while others 
>will provide XQuery as a layer on top of the engine, while others will 
>probably provide XQuery in middleware...all based on the individual 
>vendor's perception of its marketplace's requirements.
>
>Hope this helps,
>    Jim
>
>At 07:56 2003-02-28 -0800 Friday, Michael Burbidge wrote:
>
>>The XQuery specifications alludes to the fact that XQuery was designed in 
>>such a way as to be able express queries across various kinds of data, 
>>including relational databases.
>>
>>Does this mean that the FLWOR expression was designed to support
>>queries that can be performed on relational databases? Was it designed to 
>>be roughly equivalent to SQL? Given that a relational database has some 
>>mechanism for exposing XML views on relational tables, is it relatively 
>>straight forward to convert an FLWOR expressions into SQL? Do we expect 
>>that relational database vendors will implement XQuery processors that 
>>directly integrate with their databases in an efficient manner?
>>
>>Thanks,
>>Michael-
>
>========================================================================
>Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
>Oracle Corporation            Oracle Email: mailto:jim.melton@oracle.com
>1930 Viscounti Drive          Standards email: mailto:jim.melton@acm.org
>Sandy, UT 84093-1063              Personal email: mailto:jim@melton.name
>USA                                                Fax : +1.801.942.3345
>========================================================================
>=  Facts are facts.  However, any opinions expressed are the opinions  =
>=  only of myself and may or may not reflect the opinions of anybody   =
>=  else with whom I may or may not have discussed the issues at hand.  =
>========================================================================
>
Received on Friday, 7 March 2003 02:22:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 22 July 2006 00:10:18 GMT