[xquery-talk] RE: Future of XQuery and XQuery Update Faclilty
lord at emf.net
Mon Oct 22 10:05:49 PDT 2007
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
>> 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
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).
More information about the talk