XQuery as a general data processing language WAS:
[xquery-talk]XQuery and Web 2.0
kennorth at sbcglobal.net
Fri Apr 25 21:48:02 PDT 2008
Dana Florescu wrote:
>> It is VERY fortunate that XQuery does not have a traditional ACID
>> transaction model.
>> ACID transactions, with their isolation levels, and consistency
>> models, are very good for theory and database classes, but the Web does not work this way.
Let's consider the increasing complexity of transaction handling as we move from a single machine to a network to the Web.
HTML 5's use of the SQLTransaction object permits operations on a local database. The X/Open XA standard, implemented for example by Java APIs, was created for transactions that required coordination across a network. XA supports distributed transactions with a two-phase commit protocol.
The 'Internet transaction' concept (stateless clients, loose coupling, coordinating long-running transactions across multiple servers) prompted the development of new specs for distributed transactions, such as OASIS BTP and WS-Transactions. Concepts such as commit, rollback, and two-phase commit are still in play. Implementations involve an exchange of XML documents or messages, not a foreign concept to XQuery.
Consider one of those new-generation toolkits such as Google Gears. They exemplify the concept of 'general purpose' because the objective is to use the same framework for developing for the Web, the desktop and mobile devices such as smart phones. The idea is to support operations in connected mode or disconnected mode, with a local store that's used in either context. Mobile apps are affected by network latency, for example, so a local store and queuing mechanism are important.
XQuery is better positioned for the more complex, message-based Webtransaction than it is to handle the more traditional transactiontypes. So pairing XQuery with a general purpose toolkit for Web, desktop and mobile development is problematic because CRUD and local transaction support are not up to the level of support provided by a language such as Java, or even HTML 5.
So perhaps we have to revisit the concept of a 'general purpose' language - whether suitability for desktop and mobile development.is a requirement.
On Apr 25, 2008, at 2:21 PM, Ken North wrote:
> 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
> 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.
> talk at x-query.com
talk at x-query.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk