cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerström <dani...@nada.kth.se>
Subject Re: data goes in, data goes out
Date Mon, 03 Dec 2001 17:02:21 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message