- From: Cameron McCormack <cam-www-svg@aka.mcc.id.au>
- Date: Fri, 27 Feb 2004 10:40:11 +1100
- To: www-svg@w3.org
Robin Berjon:
> interface SVGXPathEvaluator : xpath::XPathEvaluator {
> void registerFunction( in DOMString NamespaceURI,
> in DOMString FunctionName,
> in EventListener function );
> }
>
> A listener taking an XPathResultList and returning an XPathResult would
> cut it. Wouldn't you then have all you need to implement CSVG on top of
> SVG 1.2?
To be honest, I hadn't looked at the DOM 3 XPath stuff before. Looks
interesting. I think a major problem though is that the CSVG extensions
rely pretty heavily on analysing the expressions used for elements'
attributes and properties to determine dependencies. If expressions can
start calling arbitrary ECMAScript, then all bets are off (at least,
I've only put effort into analysing XPath for dependencies, it *may* be
possible with ECMAScript too, but there's much more scope for it to be
harder).
I do plan on making a CSVG to SVG 1.1 + ECMAScript compiler next to see
(a) if it can all be done in SVG 1.1, and (b) what the performance is
like.
Cameron
--
Cameron McCormack
| Web: http://mcc.id.au/
| ICQ: 26955922
Received on Thursday, 26 February 2004 18:40:13 UTC