Re: [xslt] libxslt extension

[Luca Padovani <lpadovan cs unibo it>]

Hi Nicolas,

On Tue, 2004-02-03 at 23:40, Nicolas Deschildre wrote:
> Non-HTML WYSIWYG edition would behave like this: transforming the XML source 
> into HTML source so that it can be displayed and modified in a WYSIWYG way. A 
> modification in the generated HTML file will have repercussions to the 
> original XML file.

in a different context, we're doing exactly this in editex:
http://helm.cs.unibo.it/software/editex/
The differences are that
1) the target markup is MathML and not HTML
2) the user _types_ in TeX which has the effect of modifying the
internal document model (XML). Stylesheets are used to map the internal
model into a MathML document.

All is done using Daniel's libxml2 and libxslt (with appropriate
wrappers 'cause we work with DOM interfaces).

> 1) To know what are the repercussions of one change 
> (addition/modification/deletion of a Node) in the generated file do in the 
> source file as well as in the generated file itself.

I think this is very hard to do in general. In our context it is
relatively easy because the internal document and MathML almost have the
same structure. We keep pointers (read: ref+id attributes) from the
generated MathML to the internal XML so that it is possible to "go back"
if desired (think of selection). But when the document is modified, it
is the internal model which is modified, not the generated MathML (see
the model/view/controller design pattern).

> 2) To know which parts are editable or not in the generated file i.e. which 
> parts depend of the original source file.

as before you can use refs/ids to keep corresponding fragments of the
internal model/generated document related, and perhaps use some extra
attributes to annotate the tree with extra information (like "readonly"
or whatever is needed)

> Of course, i will participate to the coding if necessary, but i would like to 
> hear first if it is possible, and how hard it would be.

we haven't modified libxslt at all. If the structure of the internal
model and of the view are very different it is more difficult to make
the XSLT transformation incremental, and incrementality is essential for
performances. But to my knowledge the attempts of making incremental
XSLT engines have all failed.

HTH,
-- Luca