Re: SVG For data driven graphics

>Jacob,
>I took a quick look at the data driven graphics proposal. The SVG working 
>group has looked at several similar proposals over the past couple of 
>years, some from the public and some from the members of the working group. 
>My assessment is that your proposal has a good amount of elegance (i.e., 
>lots of power from some simple constructs) and is definitely one of the 
>better proposals I have seen.

Thanks, I'd be interested to see other works towards the same goal 
(sXBL being the closest at the moment I think).  Are there any you can point
me towards?

>I haven't studied your proposal completely, but my sense is that there 
>would need to be some additional work in order to achieve compatibility 
>with SVG's processing model. Because of SVG's history of attempting to do 
>the right thing with other W3C initiatives, there are various requirements 
>in order to extend SVG with new functionality. With regard to your 
>proposal, two things leap out at me as making it non-trivial to integrating 
>your proposal as described on your web site into SVG: all of the 
>complexities with SMIL, and the DOM2/DOM3 event model.

Actually I've been pretty impressed with SMIL.  In a nutshell, my proposal simply 
takes SMIL animation and binds this to application data rather than time.  
It's limited of course because this will only provide for linear type animation.  
Events are only used for input animations discussed in the proposal, and these use the 
DOM names/format.  I can see that a mixed document of SVG/sXBL and SVG/DDG would not 
work at present

>At least part of your functionality would be possible via sXBL components 
>sitting on top of SVG 1.2 (which supports XPath evaluation via the DOM). 
>You could have a <foo:binding> custom element defined in sXBL which 
>contained a couple of XPath expressions as attributes, where one XPath 
>pointed to the data and another pointed to an attribute in the SVG 
>document. The component could evaluate the XPath expressions, register 
>event listeners on the data (in particular, mutation event listeners), but 
>maybe also could listen for newly downloaded data. When data changed, the 
>component could update the given attribute.

Implementing a W3 recommendation which fills all the Data Driven graphics needs 
would be the most ideal.  However, it's more the description of static graphics in the 
SVG spec which I'm most interested in following strictly, and this is where I see 
the biggest benefit for interoperability lies.  I'm hopeful I won't need to diverge 
far from the W3 specs to do all that's needed.

>But once again, I haven't had time to study your proposal in detail, so 
>maybe my suggestions won't work.

I should also mention that the Application Framework at present mostly implements 
what's in the proposal.  There are some prebuilt examples at

	http://www.keystoneframework.org/download.html

>Jon Ferraiolo
>Adobe Systems, Inc.
>sXBL co-editor

>At 05:46 AM 9/29/2004, Jacob Lister wrote:
>
>>Hi all,
>>
>>It's still a little rough, but with all the discussion going on about 
>>sXBL,  I'd like to share my thoughts about dynamic SVG, and throw another 
>>approach into the mix.
>>See http://www.keystoneframework.org/doc_svgddg.html
>>
>>Jacob

Received on Friday, 1 October 2004 02:07:03 UTC