[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Update-order of XQuery Update Facility
- From: Michael Kay <mike@saxonica.com>
- To: xml-dev@lists.xml.org
- Date: Thu, 30 Aug 2012 18:00:20 +0100
Only just got around to this, flagged for attention while I was on holiday.
On 15/08/2012 07:19, Johannes.Lichtenberger wrote:
> 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).
The spec is clear here that at the point all the pending updates are
applied, it's an error if applying all the updates results in two
attributes of an element having the same name.
>
> 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">.
The spec is clear that this is allowed. Even though inserts are done
before deletes, temporary inconsistencies are allowed; it's only if the
final result after applying all the updates is inconsistent that a
dynamic error occurs.
>
>
>
> 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 ;-)).
>
Again, I think the spec is quite clear on the outcome. You do all the
inserts and deletes, then you merge adjacent text nodes.
How you implement it is another matter - that's up to you.
Michael Kay
Saxonica
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]