XQuery as a general data processing language WAS: XQuery and Web 2.0

[Ken North]

Dana Florescu wrote:
>> I don't think XQuery should be a general programming language, like in
>> implementing a network protocol in for example.
>>
>> But I think it is a great language for general data processing. It
>> does the job very well.
>>
>> If your program involves primarily data extraction, filtering,
>> transformation, creation of new pieces of information

There's a lot of innovation in developing toolkits and frameworks for building 
rich Internet applications and desktop applications. One characteristic of the 
better frameworks is database support. Software such as Google Gears and Adobe 
AIR include an SQL engine and APIs for SQL access. The 2.0 database API for 
Google Gears is following the HTML 5 Storage API (SQL).

There are a number of web and mobile development toolsets that embed an SQL 
engine, even though over-the-wire exchanges might involve XML and/or JSON.  The 
obvious question is what about XQuery?

The answer lies in part with CRUD operations and transaction semantics. The SQL 
transaction model is based on standards and concepts, such as isolation levels, 
that are well-understood. So there's nothing revolutionary if you're an HTML 5 
developer coding with an SQLTransaction object, or a Gears developer looking to 
use a transaction queue.

But assume you want to use an XML database engine and XQuery with your favorite 
Web 2.0 framework, instead of building on its SQL solution. You don't have a 
plug replacement because:

1. There's no standard for transactions with native XML databases (either 
behavior or syntax).

2. Since XQuery Update became a candidate recommendation only this year, we've 
had an extended period of XML database and XQuery products implementing their 
own extensions for CRUD operations.

3. XQuery and transactions are rarely discussed in the same sentence, except in 
the 2005 XQuery Update Requirements doc.