[RUS-WG] Status of the XQuery Update Facility

[Gilbert Netzer]

Hi everybody,

as you probably can guess I am trying to break the large considated 
comments document (http://forge.gridforum.org/sf/go/doc14370?nav=1) from 
Xiaoyu down into smaller pieces that can life on its own.

So here comes the next piece about the XQuery Update Facilities I mentioned 
earlier (I added my comment below after MY COMMENT):

[Comment 5]
“I was thinking that using XPath statement for context node orientation for 
both extraction and update. For example, RUS::modifyUsageRecords (String 
XPath, String value), could be used to modify a specific ‘urf:MachineName’. 
But I finally resort to XUpdate statement for RUS update operations because 
There are quite a few complicated use case, like the pricing system would 
insert a ‘urf:Charge’ property into usage records which cannot be handled 
by single XPath statement. What is your thinking here?” [Xiaoyu]

Evaluation
“I am considering changing the ‘XUpdate’ to ‘XQuery update Facility 
(draft)’ [http://www.w3.org/TR/xqupdate/] extensions since the XUpdate 
specification seems to not be maintained any more and never advanced beyond 
draft stage. [Gilbert]

“I think that would probably fine, but the only worry is that the W3C 
XQuery XUpdate document is still a working document. And is there any 
service implementation available in existing XML:DB engine? If no, how RUS 
implementation should enable RUS update service?” [Xiaoyu]

MY COMMENT:
At least eXist seems to support something that looks like the W3C working 
working draft, see http://exist.sourceforge.net/update_ext.html, but it is 
probably not complete yet.
One problem I can see with the XQuery languange is that it is very 
powerful. If you use the update facilities, you could possibly reduce the 
whole RUS to one method called executeXQuery that would take the query as a 
string and return the result. I don't want to suggest that, just to point 
out the power of XQuery. But that also means that you can formulate very 
"expensive" XQueries that could easily overload a RUS server.

So my suggestion is to go for XQuery, but require from the service that is 
only MUST understand a limited subset, by SHOULD try to understand (and 
execute) the whole XQuery language on a best effort base.

This way services could remain simple, and clients that want to 
interoperate know what they can send to any RUS, but more sophisticated 
services can offer more. Clients can use those facilities at their own risk.