Hello Lionel, I am very interested in this kind of execution model as I have been thinking about XML editors with an architecture very similar to the one you describe in your paper. I have several questions:
In your paper you state that this incremental transformation model has been implemented in-part in Xalan. Yet, in the eMail below you say that Xalan does not support this mode of operation. Why this discrepancy? In the paper you mention the problem of applying an inverse transformation to the target document to find out what change of the source document was intendet. Of course you know that the image of such an inverse translation does not have to be unique. Because of these difficulties I would like to suggest another way to use incXSLT, which might even be easier to implement. I do not mean to suggest that the method below is "better", though, I merely think that it is well-suited to *some* scenarios. The editor I have in mind would let the user edit the source document tree directly. Of course the editor would provide assistance to help with the creation of verbose markup such as MathML or tables, but technically only the source tree would be altered directly by the application. These changes would then be transformed and the changed result would be presented to the user. To give the user some indication of "where she is" in the source tree the position of the "cursor"/"caret" in the source tree would be mapped to a (set of) node(s) or simply a position in the target tree and this location would be highlighted visually. Such a mapping between corresponding nodes in the source and target trees would have to be kept up to date by the incremental XSLT processor. Of course it is non-trivial to define such a mapping in the first place: should (the nodes/text generated by) *every* occurence of <xsl:value-of select="my-node"/> be highlighted or only (the nodes/text generated by) occurences of <xsl:apply-templates/>? Not every answer to these questions might be optimal in every case. However, my impression is that such a map could be generated by incXSLT's described architecture. All in all I think the existence of a library allowing for incremental translation would be of great value. It might be the basis for many different editors, each tailored to the scenario it is designed for, and numerous entirely different applications as you state in your paper. I would appreciate your sharing your code with the community if you have not already done so. Are there any plans about how to proceed with the development of incXSLT? In the context of the Xalan project maybe? Please excuse this rather lengthy eMail. Cheers, Felix On Wed, 2003-02-19 at 16:03, Lionel Villard wrote: > > > Felix, > Xalan don't support incremental transformations, i.e updating the > target document after modifications in both the source document and > stylesheets. And in my best knowledge, no xslt processor allows it. > However, I know it's possible to implement such processor, just take a look > of my publication on this topic: > http://www.research.ibm.com/people/v/villard/Papiers/incXSLT.pdf > > I want to take this opportunity to ask the XSLT/Xalan community how > much you are interested in this specific execution model? > > Lionel Villard > IBM T.J Watson > > > > > > Felix Breuer > > <[EMAIL PROTECTED] To: [EMAIL PROTECTED] > > > cc: > > Subject: incremental >re-transformation of changed source document > 02/18/2003 11:40 > > AM > > Please respond to > > xalan-dev > > > > > > > > Hello! > > What I would like to have is a XSLT processor that supports the > following mode of operation: > > 1) given: a source DOM tree. > 2) apply XSLT stylesheet to source DOM tree to obtain > a) result DOM tree > b) a mapping, which maps a node in the source tree, to the set of > nodes in the result tree, which have been generated by applying > a template to the given node > 3) make XSLT processor listen to mutation events on the source tree > 4) whenever a node in the source tree is modified, the processor > a) updates the result tree > b) does so without re-transforming source nodes that have not changed > (and whose transformation-relevant context has not changed) > c) updates the source nodes -> result nodes mapping (from 2b) > > In short: What I need is a processor that keeps a source DOM tree and > its image under a given stylesheet in sync. > > Would it be possible to implement such a processor on the basis of > Xalan? > > Do you know of a processor that allows this mode of operation already or > that would at least allow the implementation of it? > > Regards, > Felix > > -- > Felix Breuer <[EMAIL PROTECTED]> > -- Felix Breuer <[EMAIL PROTECTED]>
