Avalon, XAML and SVG8:25:19 PM

There has been a ton of speculation on SVG and its relationship (or lack thereof) to Avalon.  Here is some thoughts on that, collected from various responses I've made or others have made.

• Our rendering model is very much like that of SVG.  We support a hierarchical compositing model with transforms that affect items in the hiearchy.
• Our markup isn't the same mostly because XAML is a direct reflection of the programming model.  There is a very solid relationship between the markup and the objects and methods.
• Our OM doesn't match the SVG DOM because we choose to go with an object model that more closely matches what we think our users expect.  Specifically, we tried hard to make sure that our object model provided a certain amount of consistency with WinForms (and VB and MFC before it) and ASP.Net.  Beyond this, our object model is strongly typed where much of the SVG DOM is based around strings. 
• WVG is a term that we are no longer using and isn't, in my opinion, very useful.  We were supposed to have scrubbed this from our documentation, but apparently we missed some stuff.  There is no strick subset of Avalon objects and XAML markup that stands on its own with respect to vector graphics. 
  • Whereas when using SVG inside of XHTML there is a very bright line, when using a vector graphic element in a UI authored in XAML, there is no sharp line.  You can put a Rectangle element, for example, in flow with a document without a Canvas element.  To do a similar thing with XHTML/SVG, you would need to wrap all SVG content in an SVG element. 
  • For Avalon, the set of properties and property types is the same between vector graphics elements and other elements.  In this way the background property for a Button is of type Brush -- the same as the fill property for a Rectangle.
  • There are elements that can very easily be seen to belong to both a control subset and a vector graphics subset.  For example, Image makes sense in a UI sense but also in a VG sense.  XHTML and SVG both have image elements.  We avoid this duplicity.  Text is another area where we avoid a large amount of duplication.
• While we share a rendering model with SVG to a large extent, our support and features don't match up completely.  Some of it is stuff that we haven't implemented yet and others are due to choices that we've made because of programming model concerns.  I'll try to put together a guide on this stuff at some point in the future.

I'm sure there are questions around SVG and XAML/Avalon that I haven't answered here.  Post in the comments and I'll update this post with the latest and greatest.

I hate Avalon8:18:52 PM

Actually, I'm proud of the work that we are doing on Avalon, but I hate the name.  It just sounds lame and dorky to me.  I guess this is what you get when you vote on a code name.  Aero and Indigo are much better names.  In fact, the shell team has the best code names: Aero, Jade, Luna, Plex.  I guess it is because they have designers who are creative types.

The worst code name I can think of right now was for NT4.  It started out being just and update to the shell.  So, it was called the "Shell Update Release" that got abbreviated SUR.  They even made T-Shirts that said "We don't need any stinkin' code name."

Anyone haved examples of other really bad code names for projects?