4997 2007-08-30 12:33:15 +0000 [UPD] Replace of attribute nodes can be ambiguous 2007-10-15 22:57:21 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Update Facility Working drafts PC Linux CLOSED FIXED P2 minor --- 1 john.snelson chamberl public-qt-comments oldest_to_newest 16336 0 john.snelson 2007-08-30 12:33:15 +0000 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? 16601 1 chamberl 2007-09-14 17:18:36 +0000 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 16611 2 john.snelson 2007-09-17 14:37:42 +0000 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? 16672 3 chamberl 2007-09-18 17:41:34 +0000 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 16673 4 john.snelson 2007-09-18 18:22:57 +0000 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. 17224 5 chamberl 2007-10-15 22:57:04 +0000 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)