Future XSLT processors

[Jon Smirl <jo...@mediaone.net>]

XSLT was designed for incremental processing but so far no one has built
one.  For example, right now you load HTML into a browser. If you use the
DOM to change something it is immediately reflected in the browser. You
don't need to regenerate the whole page. This is because it's easy to
implement incremental CSS.

XSLT is capable of doing the same thing. This is what xsl:fo is all about.
When the XSLT processor transformed the input XML into XSL:fo it would leave
all kinds of links between the input tree and output tree.  These links
would be used to implement incremental XSLT processing. You would then be
able to make a small change to the input XML tree and have it immediately
reflected in the output tree.

This type of engine is only useful when integrated into a browser. I wish
MS/Netscape/Opera would write one. Meanwhile we're stuck with doing a
complete retransform every time you change the input tree. Either that or
you use XML/CSS. But no one has implemented enough of CSS2 for that to be
useful.  You could build a great editable master/detail form in Powerbuilder
in 1990 but the browser still can't do it in 2000. Just look at what MS is
doing, spending $500M on building an unneeded Java killer while letting the
browser stagnate.

Jon Smirl
jonsmirl@mediaone.net