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 ;-)
Jeremy Quinn wrote: > At 4:07 pm +0100 29/11/01, Stefano Mazzocchi wrote: > >>Jeremy Quinn wrote (double quotes mean my words): > > [snip] > > >>>Incedentally, I spent some time yesterday trying to work out if standard >>>XUpdate transformation could be handled by an XSLT Stylesheet rather than >>>written in Java. I suspect it would be extremely difficult, if not >>>impossible. XSLT is not good at selecting, using dynamic XPaths (am I >>>right?). >>> >>hmmm, from a theorical perspective, if XUpdate cannot be easily >>transformed into a stylesheet, then it means they are sufficiently >>different to make XUpdate existance more interesting. Wouldn't you >>agree? >> > > This is something I would like to start thinking about, ie. how to > implement XUpdate in such a way it is controlled from the sitemap. > (Basically because this is something I am possibly capable of contributing > ,) > > There seem to be several options: > > 1. XUpdateTransformer > 2. XSLT Stylesheet which knows how to do all XUpdate transformations > 3. XSLT StyleSheet that transforms an XUpdate modification specification > into into a new XSLT StyleSheet that is then used to process the data > 4. XSP TagLib > 5. XUpdateAction > > Have I missed any? > > What information needs to be available? > > 1. The new data (Request) > 2. The XUpdate modification specification (from a pseudo protocol url) > 3. The xml fragment to be modified (from a pseudo protocol url) > 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). 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. 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. > How might each option work? > > (I am assuming for the moment that we will have some kind of SiteMap > component, that I am calling the "(?) Transformer", that does the job of > serialising a node representing the modified xml fragment to the datasource) > > 1. XUpdateTransformer > > Use aggregation or XInclude to combine into one "document", the new data, > xupdate spec and xml fragment to be modified. > > <doc> > <request> > <!-- the output of the Request or Stream Generator --> > </request> > <update> > <!-- the XUpdate modification specification --> > </update> > <source> > <!-- the xml fragment to be modified --> > </source> > </doc> > See above: request and source or update and source is probably enough. > Pipe this to the XUpdateTransformer, telling it the name of the nodes holding > "request", "update" and "source" (unless we developed a new namespace for > this). Because the XUpdate transformer would need to resolve XPaths (for > copying data) in both the "request" and "source" Nodes. > > Pipe this (now with the modified "source") to the (?) Transformer with the > name of the "source" node and a URL to have it serialised to Store. > > 2. XSLT Stylesheet which knows how to do all XUpdate transformations > > Same as 1. above I believe > > 3. XSLT StyleSheet that transforms an XUpdate modification into XSLT > that is then used to process the data > > Aggregate the "request" and the "source" as above. > Transform this with an XSLT generated by calling a separate pipeline via > the "cocoon:/" protocol that uses a standard XSLT to transform the XUpdate > modification specification into an XSLT for that job (job, not request, so > it can be cached, job represents the source-dtd/operation axis) > Transform this with the magic (?) Transformer as before. > Note: Is this XSLT generation feasible? I spent some time, a while ago, considering how to combine XSLT and XUpdate. As the variables, XPath, the condition handling and the XML-creation part of XUpdate are a subset of the corresponding mechanisms in XSLT, it seems like an attractive option to combine those two. However, IMHO, it is not worth the effort to implement XUpdate in XSLT, (although i hope that someone can prove me wrong). An XUpdate document is basically an XML packaging of a sequence of DOM operations, where the node to modify is selected by an XPath expression. The only way to simulate a modification of a document in XSLT, AFAIK, is to make a copy of all of the document except for the node that is supposed to be modified, and to insert the new node or whatever you want to do, in that place. As the copying of the whole document must be done for each XUpdate instruction, a "pure" XSLT-implementation of XUpdate would be extremely inefficient. Another problem is to locate the node to be modified, even if the node can be selected with "evalute(xpath)", XPath lacks, AFAIK, the possibility to see if two nodes are the same. Which makes it hard to see that you have found that node while traversing the dom-tree. Another possibility might be to write some extension tags that can handle updates to the XSLT-processor. But in modern XSLT-processor like Xalan2, the input is copied to a read only data structure, that is specialized to make fast XPath operations possible. So I think the main conclusion is that XSLT does not help at all. However I believe that an XSLT-dialect that acts on dom-trees, handles side effects and that allows extension tags defined in the language itself would be the be a good language for writing of XML-based web applications. While waiting for such a language ;-) I think that the best way to go is to write an XUpdate transformer in Java. If one can find a good XPath implementation that works on DOM-trees, it should not be to much work to implement an XUpdate processor, as XUpdate seem to be mainly an XML-packaging of DOM-methods, aplied on noodes selected by XPath expressions. Regards Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
