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 5340 - [UPD] Atomicity is untestable
Summary: [UPD] Atomicity is untestable
Status: CLOSED WONTFIX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Update Facility (show other bugs)
Version: Last Call drafts
Hardware: PC Windows XP
: 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: 2008-01-02 18:59 UTC by Michael Kay
Modified: 2011-01-07 11:30 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2008-01-02 18:59:03 UTC
Rule 7 of upd:applyUpdates() states "The upd:applyUpdates operation is atomic
with respect to the data model. In other words, if upd:applyUpdates terminates
normally, the resulting XDM instance reflects the result of all update
primitives; but if upd:applyUpdates raises an error, the resulting XDM instance
reflects no changes. "

I believe this is untestable and therefore doesn't belong in the spec. It's
also very unclear what requirements it is placing on the implementation. Does
it mean, for example, that streamed delivery of updated XDM instances is not
allowed unless such streamed delivery is guaranteed to succeed? I can't see any
reason for placing such an onerous requirement. But if it doesn't mean that,
what does it mean? Does it mean that implementations are required to make the
original un-updated XDM instance available to the application after an error?
That would be a strange requirement to impose, given that we say nothing about
how updated instances are made available to applications in the success case.
Perhaps it means that persistent data should be unchanged in the event of a
dynamic error? But handling of persistent data is explicitly out of scope!
Comment 1 John Snelson 2008-01-07 11:53:41 UTC
This is not only testable, I believe it's already tested in the XQuery Update test suite. The test suite only needs to assume that a resource can be retrieved before and after an update to be able to test what updates have been made on it.

It's very important to database implementations of XQuery Update like DB XML that updates are made atomically. It's more of a pain to implement for stand-alone implementations like XQilla, but I don't believe that makes it any less useful.
Comment 2 Michael Kay 2008-01-07 12:30:08 UTC
At best the tests in the test suite are testing that after an error, the XDM instance is deep-equal to the original. That's a much weaker requirement than saying it is unchanged from the original, because it can be achieved by making a copy of the original XDM without worrying about node identity. Equivalence at the level of node identity does seem to be untestable, as far as I can see. This is basically because we have nothing in the XQuery or XQuery Update specs that requires an implementation to provide an option to run two queries against "the same" XDM instance, or to compare node identity between one query evaluation and another.

(In practice, the tests that actually look at the instance after an error seem to suffer from the problem that (a) there is no schema for the source document, and (b) the query doesn't require revalidation. But let's not get distracted by problems with individual tests.)

Also, the tests suffer from the same problem as the "trivial embedding" tests in the original XQuery test suite: the appearance of atomicity depends largely on the way the test driver is coded, not on the properties of the underlying implementation. 

And I still think it's unclear what the requirements are. Is it required that an implementation provide a mode of execution in which atomicity is guaranteed, even if the XDM instance was not loaded originally from disk? Is it required that the implementation provides no mode of execution in which atomicity is not guaranteed? 

Although I agree with you that atomicity is a useful feature even for in-memory implementations, I think it's also a feature that imposes significant costs, and that for many scenarios, these costs should not be incurred unless the user explicitly says they want this feature.
Comment 3 zhen hua liu 2008-01-08 19:06:26 UTC
I think that the 'update atomcity' and 'testablity of it' are two orthorgonal issues. I agree that the 'testability' is an issue. Of course, testing using
deep-equal() is not bullet proof. However, 'testability'
should NOT affect the rule of 'update atomicity' in the spec. 

I agree that for some in memory implemetations, it is very costly to guarantee
atomicity whereas for DB based implementation, it is natural given the
transaction capability in DB.  However, given the fact that XQuery can be widely
implemented  in both DB and mid-tier in memory processor, 
it is probably better to give
an implementation a configurable choice to state if they can guarantee such atomicity.
Comment 4 Jonathan Robie 2008-02-26 15:26:53 UTC
There was no consensus for making this change at the face-to-face.

This is not testable within an update because of snapshot semantics, but the scripting extensions will make these assertions testable, and subsequent queries can also make this testable in environments that persist changes.

We define all updates in term of an XML instance, and atomicity is defined the same way. While we say nothing about how an XDM instance is made available to an application, this is not more of an issue for atomicity than it is for other aspects of the update spec. 
Comment 5 Michael Kay 2011-01-07 11:30:19 UTC
Accepted reluctantly.