OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Query decomposition [was: What niche is XQuery targeting?]

[ Lists Home | Date Index | Thread Index ]
  • To: "Michael Kay" <mike@saxonica.com>,"XML Developers List" <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] Query decomposition [was: What niche is XQuery targeting?]
  • From: "Dare Obasanjo" <dareo@microsoft.com>
  • Date: Wed, 15 Dec 2004 05:20:36 -0800
  • Thread-index: AcTia1BPxPxNLyjjQZiWVI73DUa2KwAGQvhQAAikQAo=
  • Thread-topic: [xml-dev] Query decomposition [was: What niche is XQuery targeting?]

>As for the type system mismatch, everything maps to text, and XML is
essentially text, so what's the problem? 
So you want perform a query against a backend source that only has a decimal numeric type using XPath which only has a floating point numeric type. A query on the back end source using its native query language could deliver different results from a logically equivalent query performed using XPath over in-memory XML. What do you do when you want to perform an XPath query over the data on the back end data store? What gets lost in translation? 
I sincerely hope banks aren't trivializing such impedance mismatches by sweeping them under the rug by saying 'everything maps to text'. If so tell me the names of the banks so I know to avoid using them for my banking needs. 
Eat right, Exercise, Die anyway.   


From: Michael Kay [mailto:mike@saxonica.com]
Sent: Wed 12/15/2004 1:22 AM
To: 'XML Developers List'
Subject: RE: [xml-dev] Query decomposition [was: What niche is XQuery targeting?]

> If we are querying over a bunch of back-end relational
> databases, why is
> XQuery better than some flavor of SQL?  At least the type system
> mismatch could be manageable.

There are many people who seem to think that 99% of the world's data is held
in relational databases. They are badly wrong.

I had some involvement with an internet banking application a few years ago.
When the customer logged on, all the relevant customer and account
information was assembled from various back-end systems into an XML document
which was then used as session data for the duration of the session. If I
remember rightly, there were about six back-end systems involved, and only
one was relational. The main operational transaction system was accessed by
sending an application-level CICS transaction to a mainframe. Many of the
other databases were ad-hoc, for example information about recent
interactions with the telephone call centre was in Lotus Notes.

The beauty of using XML for this kind of information integration is that it
allows the resulting data to have a much richer structure. This makes it
much easier to combine the structured data with the relatively unstructured,
and handle the semantic conflicts that occur: for example if two databases
record different phone numbers for a customer, you just capture both. That
is very much harder to do if the result has to be in relational form.

Decomposing relational queries to address multiple relational data sources
is by now a well-understood problem, but it only works if each data source
can be modelled in terms of a relational view. If the actual data is the
archive of an email mailing list, modelling it as a collection of XML
documents is probably going to be much easier. I see no reason why the same
query decomposition techniques shouldn't work with XQuery as with SQL, but
the technique will be far more powerful simply because XML is a richer

As for the type system mismatch, everything maps to text, and XML is
essentially text, so what's the problem? The fact that XML is text-based is
another benefit.

Michael Kay

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS