From Chris Sells...

"Marc Clifton, author of the MyXaml open source project, publishes a series of articles exploring opportunities for improvement for the Avalon architects to consider:

• Is Microsoft Bollixing Up XAML?--a look at "tag names are class names"
• Is Microsoft Bollixing Up XAML? -- The joys of VisualTree
• Is Microsoft Bollixing Up XAML? -- The case of the missing collection
• Is Microsoft Bollixing Up XAML? -- Decorating the house of cards"

I hate to defend stuff, generally I like the debate more than one sided... hopefully Marc will hear some of my responses and respond...

First, generally about style. Yep, Marc, you are right Style is messed up. Before we dive into the tag names are class names issues, lets address "Set"... right now it looks like we are fixing that one in a future release (I say looks like because of the standard caveats, etc... current plans always subject to change and still looking for feedback from customers, blah blah...).

The tag name issue - which for style we call "As Use" syntax - was a concious decision where Avalon broke the XAML rules.

Yes, as we have said many times, XAML is broader than Avalon. Don Box and I have shown XAML being used for console apps and more. In this case, Avalon decided that the markup model for style, strictly following the XAML rules, would have been horrible.

The problem starts with cloning. Since styles are effectively defining templates that need to be applied to multiple elements, you have the issue of defining what things need to be copied, and what can be assigned. In early builds of Avalon we used an implicit cloning model. We would create an instance of the element tree and then clone the tree, using several models for accomplishing this. It turned out not to work very well.

As part of the Avalon rearchitecture last year we moved to an explicit cloning model - enter FrameworkElementFactory. The element factor was an explicit object that would create new instances of another class and apply that style to it. Hence we could now create elements in a reasonable fashion. Of course, the markup ended up looking horrible:

<Style>
    <Style.VisualTree>
        <FrameworkElementFactory Type="DockPanel" ... />

So we came up with an alternative - what if Style had special parsing logic (by implementing an interface) and would basically switch the parser over from generating elements, to generating factories. Ah... now from an imperitive code model, we had explicit cloning, but from a markup model we had code you could understand. We then applied the same hack (uhm, i mean design) to the element explar - which gave us "<Button Background='Red' />"

I agree completely that the style tag breaks a bunch of XAML rules, and this was by design. The correct way to parse XAML is to instantiate the appropriate CLR types and inspect them for the various interfaces (IAddChild, IParseContent [or was it IParseLiteralContent?])... XAML is a way of binding XML to CLR objects.

And for the last bit - the magic missing collections... here is a continued debate on the Avalon team. Having a collection specified for every tag is a pain, so we introduced IAddChild as a way for a specific object to control the parsing of child elements and text. If we are using this interface too much, we should fix it - however the interface (and capability) is needed to support the final leaf nodes of the tree - eventually someone has to consume the text nodes in the XML document ;-)

Anyway, some of the issues that Marc brought up we are actively addressing, some we think are there by design... regardless, lets keep the conversation going and keep the feedback coming... we are listening!