- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Tue, 25 Nov 2003 17:53:24 +0200
- To: Tobias Reif <tobiasreif@pinkjuice.com>
- Cc: www-svg@w3.org
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