- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 07 Jan 2008 12:30:09 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5340 ------- Comment #2 from mike@saxonica.com 2008-01-07 12:30 ------- 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.
Received on Monday, 7 January 2008 12:30:17 UTC