[lxml-dev] Targeted XSL transformations

[Emanuele D'Arrigo]

Stefan, thank you for your reply.

2009/7/14 Stefan Behnel <stefan_ml at behnel.de>

>  > My fundamental question in this context is: how do I avoid re-applying
> the
> > xsl transformation to the whole ElementTree and only apply the bits of
> the
> > transformation that are necessary, due to the change in the tree?
>
> Hmm, to me, this description contains a bit too many uncertainties. If you
> can control the input documents, I'd rather try to make the stylesheets
> distinct and apply them in a progressing order on a clean input, instead of
> trying to figure out which XSLTs you may have to run on a document.


Hmm... the intention IS to apply distinct stylesheets in progressing order
on a clean input. But eventually that input must be used in the application
and that's when the application might add pieces that require styling and
might change the style of other elements that are already in the tree.

I.e., suppose I'm starting with just a node <aRoot /> and an xslt file that
gives the attribute color="blue" to it and the attribute color="orange" to
any of its children - when any exists. After the initial transformation I
then have <aRoot color="blue" />. Now, let's suppose the application then
does the following:

1) changes the color attribute of <aRoot /> from blue to red.
2) adds to <aRoot /> an <aChild /> node that needs to be transformed
according to the initial xslt file.

If I now apply the initial xslt to the whole tree the child node will
correctly acquire its orange color attribute, but at the same time the root
node will go back to its initial blue color when it shouldn't be touched.
-Ideally- there should be a way to apply only the transformations that are
due to the addition of the child element. This might very well be impossible
or impractical. I'm just asking if that's the case.

If you can't do that, you can try to make the XSLTs idempotent, so that
> they do not break already styled documents or subtrees. But you should
> definitely try to let different stylesheets do independent things.


Uhm... I think I understand what you mean. In the example above you are
talking about splitting the stylesheet so that the initial stylesheet is
applied and then, only when a child is added, a second stylesheet is applied
bringing only transformations that are related to the addition of the child.
Hmmm... I wonder if this can be made to work in all circumstances. I.e. in
the example above if I apply the same orange-coloring stylesheet every time
I add a child I might end up overwriting the color of children that in the
meantime has been changed from the default orange.


> My preferred solution, however: if you can avoid putting any style
> information into the (X)HTML document (or at least the style bits that
> interfere in multiple XSL docs), and move it out into a CSS file, I think
> you can get yourself out of a lot of hassle. Many of the decisions that you
> would take in XSLT to put style information in the right places can be left
> to the browser's CSS engine.


I wish I could leave that to something indeed rather than having to
implement it myself. Unfortunately, although my original post referred to
xhtml, in practice I'm not dealing with a browser nor with xhtml. Instead
I'm attempting to write a GUI system based on Mozilla's XUL.

I initially thought of using CSS but, I seem to understand, lxml only allows
me to -select- elements in the tree via css. This is quite short from
generating the cascade of css rules and transforming the tree accordingly.
For this reason I'm currently oriented toward XSLT: once a stylesheet is
ready it's quite easy to create a transform object out of it and apply it to
an xml object.

What do you think?

Manu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/lxml-dev/attachments/20090716/5eedb658/attachment.htm