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

[Daniela Florescu]

Ken,

you bring here probably the most important point in the discussion:  
transactions.

I will tell you my point of view on that, I am sure many will find it  
heretic.

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.

On the Web data is never consistent, and that's great! Transactions +  
Web = wrong choice !!!

In order to be able to scale, and to keep the costs low, new data  
consistency models
are needed, like the "almost consistency" of the Amazon S3, or maybe  
something else !?

In some sense, XML community is lucky: we don't have 30 years of  
history and baggage
to carry with us, we are free to innovate in this area. I am sure  
there will be a lot of
work around Web+XML+ consistency models, simply because it's needed.

Best regards,
Dana
(and yes, I still do work for Oracle :-)






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  
> (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.
>
>
>
>
>
>
>
> _______________________________________________
> http://x-query.com/mailman/listinfo/talk
> http://x-query.com/mailman/listinfo/talk