XQuery as a general data processing language WAS:
[xquery-talk]XQuery and Web 2.0
dflorescu at mac.com
Fri Apr 25 22:15:57 PDT 2008
> Concepts such as commit, rollback, and two-phase commit are still in
No, two phase commit isn't in play anymore, and hasn't been for a long
time (if it has ever been
more then a research toy).
( It's nick name is the "unavailability protocol", given by the same
people who actually
created and who worked on it for many, many years :-)
I can only wish good luck to the people who try to build scalable
solutions based on WS-Transactions.
Distributed transaction across the Web don't scale, or they are too
expensive to implement.
My guess is that all those new and fancy semi-structured Web databases
that we will see from Google,
Amazon, etc, will never have ACID transactions in the traditional
sense, simply because they cannot make
it scale at the level of the Web.
Who wants locks on data (XML or not) distributed and replicated the
Hence the "almost consistency" of Amazon.
I don't claim we have an answer yet. I just said that we should try to
look for one,
and that importing the good old traditional transactions as such
(without thinking) doesn't sound smart to me.
The problem of data (in)consistency models is relatively orthogonal to
the data model
(Java objects, SQL tuples or XML nodes). I simply think that, unlike
the SQL community, the XML community is free
to rethink those issues properly for the new Web context, because we
don't have the legacy.
> 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.
> > _______________________________________________
> > talk at x-query.com
> > http://x-query.com/mailman/listinfo/talk
> talk at x-query.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk