[xquery-talk] RE: Future of XQuery and XQuery Update Faclilty

[Thomas Lord]

Jonathan Robie wrote:
>
> The pending update list is purely an abstraction used internally by an 
> implementation. What benefit would there be to externalizing it in a 
> standard way? How would you propose to do this with "straight XML"?
>

I'll highlight four benefits:

1. It allows for a looser coupling between processing applications that 
plan updates and processing applications that conduct updates.

2. It avoids making XQuery harder to implement and learn.

3. It allows the full power of XQuery to be used to reflect on update 
plans.   For example, one XQuery module can compute an update plan, and 
then another module can examine that plan using ordinary XQuery to ask 
questions like "is such and such a node modified?" or "does this plan 
add a <password/> element?"

4. The "straight XML" approach does not commit to a fixed set of update 
operators -- it can be extended easily.  (E.g., add a single update 
operator that does a global rename of certain element nodes).

I see no lossage to using "straight XML" since, but for the static type 
checking rules, every XQUF programs maps easily into the straight XML 
style, and the straight XML style has greater expressive capabilities.

"How":  by treating an update facility as an optional property of the 
dynamic context of an XQuery program.   In some situations, the results 
returned by an XQuery program can be interpreted as an update plan.    
The syntax and semantics of update plans is extensible: people can 
invent new ways to describe updates.   To emulate the kinds of updates 
in XQUF, a new function would help "fn:node-id($node)" that returns a 
unique (within the dynamic context) string for each node.    The inverse 
"fn:id-node ($node)" would be helpful as well, though not obviously 
necessary.  Thus, an update plan could contain things like an 
"<xqu:insert-after>" element with the target node id saved in an 
attribute and the nodes to insert saved as children of the 
"insert-after" node.




>> It seems a horrible rule, not least because of the
>> segregation of "declare updating function" procedures from
>> "declare function" in the static type rules for XQuery.
>
> A great deal of optimization in XQuery is based on the assumption that 
> there are no side effects. Updates invalidate that assumption. Also, 
> the user generally knows that calling a function does not result in 
> changes to the underlying data. For both the compiler and the user, I 
> think it's helpful to identify functions that update.

XQUF updates do not invalidate the assumption of no side effects because 
XQUF programs return update plans, they don't actually perform 
updates.    The "straight XML" approach is similarly purely functional.  
The main design question I'm asking about is XQUFs notion that we need 
an addition to the dynamic state of XQueries (the list of pending 
updates under construction) along with new, oddly non-externalizable 
types for that new state.

I suspect the biggest inspiration for XQUF is the new dynamic state:  it 
allows programs to construct an update plan without requiring that the 
update plan be passed around as parameters.   But, there is already 
support for adding new, global, dyanamic state to an XQuery program: the 
tail-call optimization guarantee.   XQuery 1.0 programs written in an 
environment-passing style can trivially, efficiently, and accurately 
emulate XQUF.    If the only issue, in the end, is that people don't 
like hand-coding in environment-passing style, then a facility for 
syntactic abstraction would make more sense than a facility for updates 
in particular.

I suspect that part of the grand vision of XQUF is to join it up with 
additional language extensions for expressing sequential execution 
(e.g., adding sequence points to suitably declared functions).   I can 
see where people are trying to get but, it's a bit crazy.   You can get 
a very nice and expressive form of sequencing from XQuery 1.0 just by 
composing it with an IO monad (an approach that, additionally, works out 
very nicely with "straight XML" update plans).

-t