Re: [Xmldb-org-xupdate] XUpdate processing order
Brought to you by:
reinhapa
|
From: Ronald B. <rpb...@rp...> - 2005-05-11 23:29:41
|
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 |