Re: [Xmldb-org-xupdate] XUpdate processing order

[Ronald B. <rpb...@rp...>]

I finally had a chance to look at this. It certainly seems that both 
processing models are reasonable and it's easy to imagine use cases for 
both. Personally, I lean towards the second model as it feels more 
natural -- an XUpdate document is equivalent to the sequential 
application of its parts. That said, I can also imagine the XUpdate spec 
adding a processingModel attribute to xupdate:modifications with values 
"composite" and "sequential". Anybody know how XQuery is handling these 
issues?

-- Ron

John L. Clark wrote:

> Uche's recent XUpdate update[0] (heh) has renewed my interest in this
> language.  I am very interested in a diff solution for XML.  I had
> looked at XUpdate before, but hadn't found anything that seemed
> reasonable to use as a diff producing tool.  This time I looked (more
> closely) at xmldiff, and things seem more hopeful.  There is clearly a
> lot of work to do.  I started hacking on that codebase, and immediately
> saw some frustrating gaps and inconsistencies in the definition of
> XUpdate as a language.  So, let's get to work, shall we?
> 
> This may be obvious, but it seems to me that the XUpdate working draft
> could use a section on its processing model (even if that model is
> mostly what one would expect).
> 
> First, I suppose, one needs to define what is being processed.  I would
> say that given two XML documents A and B, an XUpdate document U
> describes the difference B - A, that is, a sufficient set of operations
> which, when applied to A, produce B.
> 
> As a result, the processing model would be that given A and U, one
> applies the instructions in U to the content in A to get some B.
> Clearly, an XUpdate document consists of a sequence of modifications.
> Is the intent that these modifications be applied in document order?  If
> so, do each of these modifications apply independently to A, or to an
> intermediate step formed from the result of the previous modification?
> 
> As an example of the problem, consider the following document:
> 
> A:
> ---
> <example>
>   <a/> <b/> <b/> <a/>
> </example>
> ---
> 
> and XUpdate script:
> 
> script.xup:
> ---
> <xupdate:modifications xmlns:xupdate="http://www.xmldb.org/xupdate">
>   <xupdate:insert-before select="/example/a[1]">
>     <xupdate:element name="c"/>
>   </xupdate:insert-before>
> 
>   <xupdate:remove select="/example/a[1]"/>
> 
>   <xupdate:insert-before select="/example/a[1]">
>     <xupdate:element name="c"/>
>   </xupdate:insert-before>
> </xupdate:modifications>
> ---
> 
> When applying script.xup to A, would this produce:
> 
> B1:
> ---
> <example>
>   <c/> <c/> <b/> <b/> <a/>
> </example>
> ---
> 
> or B2:
> ---
> <example>
>   <c/> <b/> <b/> <c/> <a/>
> </example>
> ---
> 
> As you can see, B1 would be correct if the modifications in script.xup
> applied directly to A, while B2 would be correct if modifications apply
> incrementally to the result of previous modifications.  Interestingly,
> the former behavior might be more "friendly" for using XUpdate in an
> XSLT environment (e.g. implementing xmlpatch, or the application of an
> XUpdate script to an in initial file, which is what I first tried to
> hack together in XSLT).  I'm not convinced that trying to do this sort
> of XUpdate processing with XSLT is advisable, but it sure is tempting,
> given the similarities.  Regardless, the B1 behavior may simply be
> inconsistent (although I can imagine some distinct weirdness in the B2
> case as well); I've haven't investigated it fully.
> 
> Take care,
> 
>     John L. Clark
> 
> [0] http://www.oreillynet.com/pub/wlg/6935