Re: Newbie question: Mathematical functions?

Cameron McCormack wrote:
> Robin Berjon:
>>This is interesting. Is there any reason you didn't use XPath to encode 
>>the expressions?
> 
> I did use XPath syntax, but in the prototype available on the web site
> at the moment I used functions to get the attributes, as I hadn't found
> an easy way to get expressions like id('r')/@width to get the current
> value of the width constraint, and not just the string value of the
> width attribute.

Yes, sorry, I should have been clearer. I meant XPath paths.

> In my next iteration of the CSVG extensions I have managed to do this,
> however, and the syntax is much nicer.  Constrained attributes are
> declared like this:
> 
>   <rect id="r" x="50" .../>
>   <rect x="0" y="0" width="100" height="100">
>     <c:constraint attributeName="x" value="id('r')/@x"/>
>   </rect>
> 
> The second rect has a default x value of 0, and if the browser
> understands the constraint extensions, its x value will track the x
> value of the rect with id 'r'.  I've tried to make this new syntax
> parallel the way animation works so that it could be more easily
> integrated into Batik.

This is indeed much nicer, and something that I like very much. I've 
toyed with something slightly different in which I stated the constraint 
in an attribute with the same local name but in my own namespace, it 
would map roughly to:

   <rect x="0" y="0" width="100" height="100" c:x='id('r')/@x'/>

but I think your approach is cleaner. In SVG 1.2 RCC and DOM 3 XPath 
should allow you to implement that as an RCC extension, have you 
considered doing so? Is there anything you see in the current draft that 
would prevent you from doing so?

Also, I've been working on a document defining a set of SVG extensions 
to XPath which covers some of the functions you list on the site. 
Basically it includes things like bbox() but puts them in the SVG 
namespace so that those functions are called as svg:bbox() (which in 
turn means you need that namespace context). Your version appears to add 
a some new types to XPath (eg SVGRect) which is something that I'd 
rather avoid as it will not be easy to build as an extension to most 
XPath libs (that tend to allow new functions but not new types). In my 
approach, something like svg:bbox() would return a node-set containing 
the XPath equivalent of <rect x='12' .../> so that it can be used with 
any other part of XPath with consistent semantics. You'd access the x as 
svg:bbox(.)/@x. If you have thoughts on this they are most welcome, and 
if you think there would be value in having a more generally agreed upon 
set of SVG functions for XPath I'd be happy to move this closer to the 
top of my priority pile.

Of course, as currently specified one cannot add one's own extension 
functions to DOM 3 XPath. If you believe it would be useful to be able 
to do so, please outline some use cases on this list.

-- 
Robin Berjon

Received on Wednesday, 4 February 2004 08:20:18 UTC