This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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!
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.
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.
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.
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.
Accepted reluctantly.