Re: [SVG1.2] implementing XSLT

On Tue 2003-11-25 Robin Berjon wrote:
> 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!

Yes. As with many if not most types of XPath patterns the number of
returned nodes depends exclusively on the input. //foo my return zero,
one, or five million nodes, depending on the tree it's executed
against.

> >>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 :)

You wrote "probably".

> Having implemented an XSLT processor 

Interesting! Is it available online?

> 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.

It sure requires substantial effort, no doubt.

> 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

That's why I thought it might be one possible strategy to use or
reference parts of XSLT 1.0 in SVG 1.2, and wait with XSLT 2.0 until
SVG 2.0, so that we ...

> (or won't implement before xmas 2006).

... see it implemented before christmas 2006 :)

Tobi

-- 
http://www.pinkjuice.com/

Received on Wednesday, 26 November 2003 09:53:02 UTC