This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I believe the following update query is ambiguous: copy $in := <employee name="Rhys Evans" gender="male"/> modify ( do replace $in/@name with attribute {"salary"} {"10"}, do replace $in/@gender with attribute {"name"} {"Blodwyn Jones"} ) return $in In this case, should the result be err:XUDY0021 because the second replace adds an attribute that already exists? Or should the transform succeed because the first replace removes the attribute that the second replace clashes with?
Hi John, I believe that the suggested transform expression will succeed. I see nothing in the update spec to suggest that an error will be raised. Each of the replace expressions will generate a upd:replaceNode() primitive on the Pending Update List. Finally upd:applyUpdates() will make these primitives effective, in either order. The Data Model instance will go through a temporarily invalid state but the final result is valid and unambiguous. The check for validity of the XDM takes place in Step 6 of upd:applyUpdates(), at which time the XDM is valid. In fact, you could even change your example to the following one, in which two attributes are "swapped": copy $in := <employee name="Rhys Evans" gender="male"/> modify ( replace node $in/@name with $in/@gender, replace node $in/@gender with $in/@name ) return $in This strange and entirely unmotivated expression is not an error. It returns an <employee> node that is effectively the same as the constructed one, since order of attributes is not significant. Regards, Don Chamberlin
On looking at this further, I agree with your assessment of this. If there isn't one already, can I ask that a note is added to the specification to state that the data model may be transitionally invalid during the application of the update primitives?
In the semantic specification for upd:applyUpdates (Section 3.2.2), Steps 1 through 5 describe how pending updates are applied. Then Step 6 calls for a check of data model constraints. Since checking of data model constraints is explicitly called for in Step 6 and not in any previous step, I think it is clear that these constraints may be transiently violated during the process of applying individual updates. Regards, --Don Chamberlin
I disagree that it is as clear as you say it is, because at least one person has already misread this. I think a note would aid reading of the spec.
As instructed by the working group, I have added the following Note to Step 6 of upd:applyUpdates: "During processing of a pending update list, an XDM instance may temporarily violate a data model constraint. An error is raised only if a constraint remains unsatisfied at the conclusion of upd:applyUpdates." Regards, Don Chamberlin (for the Query Working Group)