Re: [SVG1.2] implementing XSLT

Hi Tobi,

Tobias Reif wrote:
> On Mon 2003-11-24 Robin Berjon wrote:
>>[...] Generally speaking, I think one should understand "XSLT" as
>>meaning "XSLT 1.0" until 2.0 pans out.
> 
> Then the issue described in
> 
> http://www.w3.org/TR/SVG12/#rcc-openissues
> 11:
> "If a declarative syntax is used, SVG implementations may be required
> to support XPath and some simple XSLT features. Will the XSLT features
> be too much of an implementation burden?"
> 
> ... will not be a major problem for many implementers since XSLT 1 is widely
> implemented already and there are fast C libs available such as libxslt [1] and
> various implementations in other programming languages.

It is not that simple and straightforward. XSLT is a batch language
meant for the transformation of a static input to a static output. RCC
on the other hand defines bindings between multiple interacting dynamic
trees.

If you take XSLT and inject autoregeneration of the output based on
mutation events and script, then either you have to rerun the entire
stylesheet for every mutation event -- which would be way too slow and
would cause poor UI response -- or you have to maintain a dependency
graph between templates, source nodes, and produced nodes -- which is a
difficult and coslty problem to solve. Also XSLT has copy semantics but
no reference semantics (compare <xsl:apply-templates/> with
<svg:refContent/>) which means that using XSLT any script modified data
(such as event listeners for instance) will be lost every time the tree
or tree fragment is re-evaluated.

This is a "Green Revolution" problem. In the 70s and 80s some NGOs tried
to boost agriculture in some third-world countries. In some cases it
worked really well, and so they decided to apply the exact same methods
in totally different countries, with different climates and societies,
and that resulted in humanitarian and ecological disaster. Similarly,
just because XSLT works marvellously well in batch-oriented situations
doesn't mean that we can just drag and drop it into an SVG environment
and expect it to work out of the box.

To take just the issue of partial regeneration (ie not having to rerun
the entire stylesheet for every small change on a source node) there are
advanced and competent labs studying the problem that are still finding
issues in this space. So while I would personally love to see XSLT
integrated more closely with SVG when it is possible, I have very
serious misgivings about doing it within the SVG 1.2 time-frame and
would much rather it were very carefully studied, with the help of
outside sources that have built experience in the field, and integrated
as part of the SVG 2.0 effort.

Thanks for your input,

-- 
Robin Berjon

Received on Tuesday, 25 November 2003 08:49:19 UTC