This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2796 - [ScriptReq] updating nodes, then returning values computed from them
Summary: [ScriptReq] updating nodes, then returning values computed from them
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Scripting Extensions 3.0 (show other bugs)
Version: Working drafts
Hardware: Macintosh All
: P2 normal
Target Milestone: ---
Assignee: Andrew Eisenberg
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-02 15:27 UTC by Daniela Florescu
Modified: 2007-06-29 08:32 UTC (History)
2 users (show)

See Also:


Attachments

Description Daniela Florescu 2006-02-02 15:27:56 UTC
It is unclear if the current XQuery update specification satisfies the use cases that need 
to update some nodes and then return the updated nodes or something computed 
from them. Example: increase the salaries of all employees whose pay is less than their 
bonus, and return these employee nodes. Note that it is not sufficient to perform the 
update and then search for the updated nodes, because the original predicate will no 
longer yield the  same results.
Comment 1 Mary Holstege 2006-04-04 15:23:37 UTC
This is related to 2794, I believe. The current rules are overly draconian.
They forbid so many use cases as to border on the unusable:
* create a function that, if some condition is met, performs an update and
returns true or false depending on whether the update was performed
* perform a series of insertions and return a count of how many were performed
* implement a simple queue: insert appends a child element, remove removes
  the first element and returns it
* delete an item in an invoice and return an XHTML rendering of the new invoice... etc. etc.

In short, any real application that wants to communicate results to the user
is forbidden by the rule that update expressions must be pure update expressions.  The only legitimate means of reporting an error is to crash
the entire application with fn:error. 

There is no reason for this restriction. Pending update lists are side effects;
so make the do expression have a value of empty sequence. The spec would
be much simplified as a result, and more usable besides.  All the special
rules for typeswitch, if-then-else, etc. go away.
Comment 2 Tony Santangelo 2006-07-23 23:19:09 UTC
I'm distressed to find that the Working Draft of 11 July 2006 still does not address this issue. The current spec seems to make it impossible, for example, to express web application logic in XQuery. If even top-level queries must either return a value OR perform an update, but never both, then *something* (other than XQuery) is going to have to co-ordinate the response to requests that involve updates. And the revolution is once again deferred.

The update model currently used in eXist, a native XML DBMS,  (http://exist.sourceforge.net) has the characteristic described in Comment #1: update expressions evaluate to the empty sequence. This tool drastically reduces the pain of web development.

Please allow XQuery (with Update) to be a programming language, not just a query language.
Comment 3 Daniela Florescu 2006-08-24 21:57:21 UTC
Tony,

Personally I am also convinced that the real utility of XQuery will be attained only after
we add enough functionakity to make it a  full (and easy to use) programming language
-- targeted at XML processing of course, not a general purpose programming language.

Some of us we have been working in this direction. We proposed an extension called 
XQueryP (www.ximep-2006.org/papers/Paper-Chamberlin-Carey.pdf) by adding
a small number of extensions like variable assignement, sequential/deterministic
evaluation order in case of side-effects and such.

Everything being said, your comment unfortunatelly does not give us enough 
details in terms of what kind of features would you like to see in XQuery in the
future. A "programming language" is too general for us to understand your intent.

In order to help the process it would be really good if you could give us a detailed
description of the features you would like to see, together with some use cases that
you consider important. For example, would something like XQueryP be a good
solution for you ?

Thanks, best regards
Dana





(In reply to comment #2)
> I'm distressed to find that the Working Draft of 11 July 2006 still does not
> address this issue. The current spec seems to make it impossible, for example,
> to express web application logic in XQuery. If even top-level queries must
> either return a value OR perform an update, but never both, then *something*
> (other than XQuery) is going to have to co-ordinate the response to requests
> that involve updates. And the revolution is once again deferred.
> 
> The update model currently used in eXist, a native XML DBMS, 
> (http://exist.sourceforge.net) has the characteristic described in Comment #1:
> update expressions evaluate to the empty sequence. This tool drastically
> reduces the pain of web development.
> 
> Please allow XQuery (with Update) to be a programming language, not just a
> query language.
> 
Comment 4 Jim Melton 2007-06-29 08:29:45 UTC
This requirement has been accepted for the Scripting Extensions, but not for the Update Facility itself.