RE: Future of XQuery and XQuery Update Faclilty

[Thomas Lord]

Michael Kay wrote:
>> I don't follow you.   I don't see that at all.
>>
>>     
>
> Well, the language semantics are expressed in terms of pending update lists,
> and you want to expose those pending update lists to the user. But an
> implementation only has to behave "as if" there were a pending update list.
> Internally, it might do the update immediately, detect conflicts as they
> arise, and roll back to the original state if there is a failure. You're
> making it quite difficult to implement it that way if the PUL is visible to
> user applications.
>   

Thanks!  That's a great clarification.  Let's play poker:

I see your concern, but I raise you a solution:

If, in some context, an XQuery is expected to yield a "plain XML"
description of pending updates, then it can lazily evaluate these
results, optimistically performing updates in exactly the manner you
describe, as the query itself is still running.

Oddly enough, you could code exactly that, today, using
the already extant Oracle DB XML API (formerly Berkeley
DB XML).  It's low-level hooks into deadlock detection and
hooks for managing cache coherency etc. give you enough bits
and pieces to put that together.   At the same time, it's a clean and
simple enough API that other systems ought to consider emulating
it.



> In the case of XQuery implementations built on top of an RDBMS, I would
> think they are likely to use the transaction manager of the database
> service.
>
>   

Red herring.

-t