Re: [SVG1.2] implementing XSLT

Tobias Reif wrote:
> On Tue 2003-11-25 Robin Berjon wrote:
>>Actually I'm trying to think of a single XSLT construct that doesn't
>>need to be very heavily changed and can't find one. Sure, you might
>>be able to reuse little bits of code here and there,
> 
> Yes, many parts of XPath might be reusable. Executing a simple XPath
> against a given tree would probably work quite similiarly, no?

XPath isn't really the problem. The latest draft adds DOM 3 XPath rather 
unequivocally. However XSLT already requires more than just XPath 
selecting, it adds XPath matching (required for patterns). In order to 
do incremental transformation, you need to know what your output depends 
on in its source. That's something you get (in part) from XPath that 
normal XSLT doesn't care about at all. There is a number of ways in 
which one can get a list of dependencies from an XPath expression, some 
naive that'll eat all your memory, some smarter. But it will require a 
solid amount of work.

For instance, what are the potential dependencies of 
foo[@bar=//dahut/@bar] which does little more than match any foo that 
has a bar attribute equal to that of any other dahut? You may find 
yourself watching a lot of nodes very quickly!

>>but honestly you'll probably spend more time looking for them than
>>you would reimplementing them.
> 
> I don't think this type of vague speculation (on both sides :) brings
> us any further, so let's see what implementers will actually say and
> do.

This isn't vague speculation :) Having implemented an XSLT processor 
I've tried to think of the changes that would be required to do 
incremental transforming (using XSLT, it's easier if you can reinvent a 
language of your own to do it) and I can't think of a way to do it that 
wouldn't represent a fairly massive effort. I'd love to work on it if I 
had the time of course.

And more importantly, at this point the question isn't "can it be done, 
somehow, someday, under what conditions" but "can it be implemented in 
the SVG 1.2 time-frame at reasonable cost, or is it too hard to do now 
and needs to be taken out of the draft and looked into again later". As 
you said earlier, there's no point in putting features in the spec that 
people won't implement (or won't implement before xmas 2006).

-- 
Robin Berjon

Received on Tuesday, 25 November 2003 10:54:23 UTC