Daniel Fagerström wrote: > > I didn't succeed in sending this a few days ago (at least I think so, > otherwise I apologize for poluting your mailboxes). I describe why I > belive that it would be hard to implement XUpdate in XSLT. If you still > consider doing it after the "Personal comments on XUpdate" thread ;-)
right :) [snip] > I believe that one only needs the XUpdate document and the XML fragment > to be modified as input to the "XUpdate transformer". AFAIK XUpdate > documents are like patch files and includes all information that is to > be inserted in the XML fragment. > > This leads to the question of how to obtain the XUpdate document. One > possibility is to generate XUpdate directives or something that is > easily transformable to XUpdate directly in the browser. This > alternative could for example be useful in a browser based content > editor (like those discussed in the "Sharing microsoft experience" > thread). I've written such client side code and I can tell you that it's much easier, at least for me, to come up with normal serializing behavior on the client side and let the server do all the transformation/adaptation tricks on the document. Moreover, coming up with XUpdate and XPath information on the client side might require some 'context' to be added to the server response. No, I don't think this is a good solution. > In such a browser there is in any case a need for storing a > sequence of editing commands to make undo operations possible. A > drawback with this alternative is that it requires a lot of, probably > non portable, java script programming. All the 'undo|redo' operations are not necessarely structured, they could work on the client-side DOM or being transparently handled by the browser (Mozilla does this). We then serialize the DOM later on, I don't see the need to take care of XPaths on the client side. > Another possibility is run an XMLDiff on the new data and the XML > fragment to be modified. I know about one XMLDiff > http://www.logilab.org/xmldiff/ that produces XUpdate, unfortunately > it is written in Python and GPL:ed. Maybe there are XMLDiff:s written > in Java and with ASFL compatible licenses? The XMLDiff alternative > requires the input data to be transformed to an XML fragment on the same > form as the XML fragment to be modified. But I think that has to be done > anyhow, as it is unpractical to handle the same information in several > different formats. Look at this working example: 1) you request a document from an storage (somehow). 2) you edit the document on the client side (somehow). 3) you send back the document to the server (somehow). now, with XUpdate you need to 4) get the original document (either by asking it again from the storage or having saved it in cache locally) 5) obtain an xupdate description of the diff between the two documents 6) send the xupdate to the storage instead, my vision is something like: 4) send the new document to the storage. The result is *EXACTLY* the same, but I didn't have to come up with the diff myself since the storage already has the old and the new location. Think of CVS: when you commit your work, it's the server to perform the DIFF for you, it's not you that request the old document, create the diff and post that. XUpdate is a way to encode XML diffs with an XML syntax. I continue to fail to see the need for such a language. Don't get me wrong: I *do* see the need for the ability to indicate how to prepend/replace/append elements to existing elements, but this is, again, something for an API, not for a markup language. To me, XUpdate is FS distilled into markup. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
