[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]