[
Lists Home |
Date Index |
Thread Index
]
Good enough. It seems to confirm a document model paradigm. Is
that right?
But that query sure is uglier than SQL. Maybe it is the beholder thing.
It will be interesting to see how one trains people for developing
these. In other words, it took years to get them to accept and
build tables and reports. Now it is as if they have to build
reports (documents) first, and code to the report structures instead
of the underlying tables. Somehow that doesn't feel like progress.
What am I missing? (yes, I was a technical writer and a document
wonk for eight years and a markup hypertext designer for the
next ten; but after doing relational work, that seems long ago).
len
-----Original Message-----
From: Jonathan Robie [mailto:jonathan.robie@datadirect-technologies.com]
At 12:39 PM 9/25/2002 -0500, Bullard, Claude L (Len) wrote:
>I'm curious, Jonathan, because this corresponds to the integration
>thread I was posting to. What are the cost benefits of X-Query
>over say, SQL? Is this simply to be able to program to a document
>model API (ie, Infoset-based?)
One of the benefits of XQuery is that it takes XML as input and creates XML
as output, without requiring the user to work in several different
languages with several different type systems. Most data is exchanged as
XML, but stored as relational data, and the tools used to transform between
the two representations may involve Java, XSLT, SQL, the DOM...and that
means they are also dealing with distinct type systems.
Another advantage of XQuery is that it is particularly good for views of
data. An example of this is a query that joins an XML document to an
SQL/XML view of a relational database. Consider the SOAP primer. For the
first example, I need to be able to join departurer cities to airports. You
can do that with an XQuery like this:
let $src := "jdbc:datadirect:sqlserver://localhost:1433;database='airports'"
for $city in input()//p:departing
return
let $airports := xq:collection($src)/AIRPORTS/row[CITY = $city]
return
if (count($airports) = 0) then <error> No airports found for
{$city}!</error>
else if (count($airports) = 1) then <airport>{
string-value($airports/CITY) }</airport>
else if (count($airports) > 1) then
<airportChoices>
{
for $c in $airports/AIRPORT
return (string-value( $c ), " ")
}
</airportChoices>
else ()
The user need not be concerned with the details of how the database is
represented as XML or the input document is parsed and bound.
This approach is high-level, declarative, and requires very little code.
Jonathan
|
