You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Felix Breuer <fe...@fbreuer.de> on 2003/02/18 17:40:17 UTC
incremental re-transformation of changed source document
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 <fe...@fbreuer.de>
Re: incremental re-transformation of changed source document
Posted by Lionel Villard <vi...@us.ibm.com>.
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
Re: incremental re-transformation of changed source document
Posted by Felix Breuer <fe...@fbreuer.de>.
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
> <felix@fbreuer.de To: xalan-dev@xml.apache.org
> > 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 <fe...@fbreuer.de>
>
--
Felix Breuer <fe...@fbreuer.de>
Re: incremental re-transformation of changed source document
Posted by Lionel Villard <vi...@us.ibm.com>.
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
<felix@fbreuer.de To: xalan-dev@xml.apache.org
> 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 <fe...@fbreuer.de>