RE: [UPD] Compatibility rules in applyUpdates

Firstly, a plea: it makes life very much easier within the Working Group if
you use the bugzilla system to enter comments. This is far more useful than
a threaded mail archive in bringing up all the discussion and history of a
single topic, and in enabling the WG chairs and editors to keep track of
outstanding issues.

I agree that the compatibility rules for updates (clause 1 of 3.2.2) seem a
little arbitrary, and I nearly made similar comments myself. But on closer
inspection I think there is some rationale: they are the minimum set of
rules to ensure that after sorting the PUL as described in clause 2, the
effect of applying the updates is unambiguous. So there is no conflict
between a rename and a delete because clause 2 says the node is first
renamed, and then deleted.

(I love the entry in App G bullet 3 that says "Reason: this was a decision
of the Working Group"! I think what the editor is saying is "this decision
is arbitrary but we had to make a decision one way or the other.) 

> it is unclear how and when incompatibility errors would 
> be reported to users

Clearly there has to be some kind of API for invoking an Update as a whole,
and one would expect the error to be reported in response to that
invocation.

> It seems simpler to report errors as they occur, that 
> is, during execution of the update primitive (and not during
upd:applyUpdates).

That's permitted but not required, see the rules for upd:mergeUpdates. I'm
not sure what the WGs thinking was on this - perhaps there are scenarios
such as parallel execusion where it's easier to do all the consistency
checking at the end.

> c) It would be nice if such incompatibility detection were 
> optional, for debugging purpose.

I'm sure that the conformance rules don't stop someone providing a debugger
that displays a "what if" scenario showing what would happen if the
incompatibilities were not detected. But I don't think the spec should be
written to cover such scenarios. Clearly if you rename the same node twice
then there are two possible outcomes.

All personal views, of course.

Michael Kay
Saxonica

Received on Friday, 25 January 2008 11:57:06 UTC