Hi Felix,
> 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?
The *public* version of Xalan doesn't support incremental transformation...
> 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.
The editor I decribed do exactly the same thing: only the source document
is technically modified, either directly from a source view or
directly/indirectly from a target view. By directly I mean for example that
on the target view when you hit the 'enter' key within a xhtml:p element
then the docbook:para is inserted directly in the source document.
Obviously in this case, it's not possible to compute automatically such
mapping. A indirect modification is for instance when the value of an
attribute is transformed to the xhmtl:p content. If this case, when the
content of the xhtml:p element is changed, then you can easily and
automatically go back to the source document and change the attribute
value. Indirectly because you need to pass through the transformation, in
the reverse sens. For more information about this process, you can read
this paper:
http://www.research.ibm.com/people/v/villard/Papiers/XSLTAuthoring.zip and
if you speak french my phd chapter 5:
http://www.research.ibm.com/people/v/villard/These/These.pdf
> 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.
Technically, the mapping is not a big issue. Visually, it is harder, many
user interface issues. incXSLT deals only with the technical issue.
> 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?
Well that depends on how much the community is interested of such
features.... Is there anyone else here interested by incremental
transformations in Xalan ?
Lionel
