OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Update-order of XQuery Update Facility

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS