Avalon Versus SVG-RCC

Alright, I just I’ve been quite for far too long, and I feel like trying to stir up some googlejuice, and this is just the topic to do.

The people that know me for a while have seen my forays into declarative user interfaces, and the attempts to extend the concepts behind HTML into a much richer UI definition language.  I got hooked once I fell into the XML camp, and started to use Element Behaviors to extend HTML.  I picked up Adobe’s SVG Element Behavior experiment and enhanced it.  I then worked with Adobe to get the 3.0 version of the viewer to support binary behaviors (the binary version of element behaviors).  The next natural progression was to create my own element behaviors which rendered not to HTML but to SVG.  My Angular Gauges and Bar Chart examples are nice snapshots of those experiments (requires Adobe’s SVG Viewer).  I then hit upon the idea of migrating the custom namespace idea from the element behavior HTML world into the SVG document, and came up with a much cleaner implementation that didn’t rely on an IE (windows only) technology (seen here). 

At this point I started to wonder if we could eventually create a SVG rendering engine for the .Net platform (which became the SharpVectorGraphics project).  The hope was that eventually we could add other namespaces to the project and have them render as SVG, which would then render to the native graphics layer (DirectX).  Combine that with the abilities of the CLR, and you would have one powerful UI development tool.

It was at this point that I started to hear rumors of a similar architecture being developed at MS.  An UI architecture that would allow a developer to declaratively create/combine UI elements.  But instead of rendering directly to the graphics layer, render to an intermediate XML based vector graphics layer (see my previous post on Serializing User Interfaces).  Well that’s when I knew I was on the right track, and I finally get to see Avalon in a couple weeks at the PDC.

But if you thought the W3C was going to let MS roll out this new technology without a version to call their own and make so sort of an attempt to compete, well you would be wrong.  They are busy working on the latest version of the SVG spec (1.2) that will include a very similar GUI architecture called RCC (Rendering Custom Content), that they also have been working on for a long time.  The basis of RCC is very similar to Avalon, create custom namespaces, bind them to a composition engine (RCC) and have them render to a vector graphics intermediate language (SVG).  Adobe has even release a pre-beta version of their SVG viewer that uses an early version of the RCC spec.  If you want to check want all the fuss is about, install the pre-beta viewer and hit the SVG-Wiki site.  The UI element example is the one you may want to pay special attention to.

So the way I see it, Avalon and SVG-RCC are going to go head to head for the next generation GUI architecture.  We are still way early in the development life cycle and things can change, but no matter what it should be a very interesting adventure.  If you thought HTML really change the way we develop apps, and think web services are cool, just wait until you get a hold of this new stuff.  BTW, the XUL guys have a cool technology, but it misses the mark.  It can’t handle custom content, and it doesn’t render to a vector graphics layer so you can’t abstract out the different platform graphics APIs.



  • Just a note: you give the impression that the W3C is playing catchup by not letting "MS roll out this new technology without a version to call their own and make so sort of an attempt to compete". That's a mischaracterisation. RCC has been around on the WG for very long, even if it is only appearing in drafts now. And I don't remember anyone there mentionning Microsoft's stuff until recently (even when Microsoft employees came visit, they said they'd love to have SVG in MS products :).

  • You are correct, it could be read that way, so I've adjusted the wording.


  • If you are looking for a vector solution today flash is far more advanced than any of these technologies has even spec'd yet.

  • hey and what about XFORMS


  • Check out Steve's great response to my post. I love constructive discussions like this.


  • Flash is for creating interfaces that trancend the limitations of xml forms based applications; be it HTML, XFORMS or SVG. Your post is ill informed, Flash can and does parse, load and generate XML <i>data</i>. Not only this, but using dataproviders, schema and bindings you can map any XML to a data aware UI component. As a professional you should strive to actually research a technology before making false statements about it.

  • Don's right. SVG and Avalon VG are the future. No more dependency on screen resolution, etc. Play around with Avalon and you'll begin to see why it's the future.

  • Brian: Flash can handle XML, but a flash clip is not described in XML, but in a proprietary binary format that you cannot easily modify with a text editor.

    The discussion is not about being able to handle XML (all modern development tools do that now), but about declaratively define a GUI using XML, and mapping XML elements with programmatic custom objects.

Comments have been disabled for this content.