[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Update-order of XQuery Update Facility

• From: "Johannes.Lichtenberger" <Johannes.Lichtenberger@uni-konstanz.de>
• To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
• Date: Wed, 15 Aug 2012 08:19:35 +0200

Hello,

I've seen some XQuery Update Facility implementations on top of DOM-like 
tree-structures which for instance prohibit two attributes with the same 
QName and the same target element-node. In our case we (or I ;-)) set a 
new attribute-value if the QNames are identical but the values differ. 
This is to provide a DOM-like Java-API on the tree-structure and to 
apply updates on the fly (but obviously persisted only once the 
transaction is commited).

However, both approaches fail for instance in the following case:

   insert node attribute {"foo"} {"baz"} into /root,
   delete node /root/@foo

with a simple document like this:

<root foo="bar">

it temporally yields two attributes with the same QName, however 
foo="bar" is deleted afterwards which yields <root foo="baz">.

In order to avoid such cases we maybe could also split the 
delete-operation for attributes/namespaces (non-structural nodes) and 
all other node kinds.

That is first deletions of non-structural nodes and then the order 
specified in the specification. At least that's just a quick thought, 
but it shouldn't have any side-effects.

But on the downside adjacent text-nodes are also merged on the fly which 
introduces side-effects (for instance once inserting a new right-sibling 
text node of a text node which is merged with the left one and a 
subsequent deletion of the old text node). Maybe in our case we have to 
search for such cases beforehand and apply these deletions at first (or 
simply apply all deletions at first, which obviously also results in 
another, most probably unexpected update behavior ;-)).

kind regards,
Johannes