2796 2006-02-02 15:27:56 +0000 [ScriptReq] updating nodes, then returning values computed from them 2007-06-29 08:32:14 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Scripting Extensions 3.0 Working drafts Macintosh All CLOSED FIXED P2 normal --- 1 dflorescu andrew.eisenberg martin tony.santangelo public-qt-comments oldest_to_newest 8106 0 dflorescu 2006-02-02 15:27:56 +0000 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. 9024 1 holstege 2006-04-04 15:23:37 +0000 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. 10653 2 tony.santangelo 2006-07-23 23:19:09 +0000 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. 11266 3 dflorescu 2006-08-24 21:57:21 +0000 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. > 15725 4 jim.melton 2007-06-29 08:29:45 +0000 This requirement has been accepted for the Scripting Extensions, but not for the Update Facility itself.