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!

My latest article seems to have appeared up on MSDN... The Blinking Lights Division is this month's (or bi-month's) column in Inside Avalon...

Wesner has been spending time with color, the good old color from WinForms. Interestingly enough, there are reasons for the odd behavior he describes...

When working on WinForms and ASP.NET we really wanted to unify some of the system types, and color was a pretty problematic one. The issue was that ASP.NET wanted to allow all the oddities of HTML (including the ability to use bogus or out of range values) for color, while WinForms wanted to allow all the oddities of User and GDI+ (including system colors that represent a logical color). The solution - lets to it all!

So the Color class was born.

We debated a lot internally if Color should be 64-bit scRGB or 32-bit RGB... in the end GDI+ (if i recall correctly) ended up punting on full 64-bit support for color, however we knew in the future they would want to move there. The internal data structure of color therefore uses a 64-bit value to store the color, but only ever utalizes the first 32-bits.

Next, to support the various ASP.NET round tripping issues, we needed to store the string name of the color.

Finally, we have a state bit to determine what is determining the color - basically is this a natural RGB, known color, or named color. Known colors are just the magic colors that are part of the web and win32 built in color set (Red, ControlText, etc.). We wanted to track the known colors both for dealing with the whacky Win32 system colors, and to preserve the knowledge that a color was specified as "red" not as 255,0,0.

That is what we have today - a big color class that can do a lot, but has a lot of idosyncricies...

In Avalon we are moving to a full 64-bit color engine (native scRGB support) with support for multiple color spaces (you can specify colors in CMYK, etc.). Our color object won't be shared by ASP.NET, so we don't have some of the name based stuff that we have to worry about, and right now our plan is not to support Win32 system colors - but rather to solve the same problem using our styling and resource system to have a more natural and evolvable system instead of the magic colors.

A couple points...

1. Why didn't Nikhil tell me he was doing something this cool?
2. Yes, Nikhil is the guy that wrote "Web Matrix" in his spare time
3. Nikhil is one of the few developers that I have met that is also a great graphi designer

Check out his very cool bexier spline designer...

Tim comments on the London ISV event [via Scoble]... "I had wondered whether Microsoft might rewrite MSHTML in managed code, or else create a Longhorn web browser that converts HTML to Avalon rich text. Chris said no. He said that MSHTML is a complex body of code which does an extraordinary job of rendering even malformed HTML. Since the Internet works on the assumption that this kind of web page renders successfully, and since there are so many quirks and workarounds in MSHTML, Microsoft's developers did not dare to replace it. I hope I'm representing Chris's comments accurately. In essence, it suggests that IE will remain broadly as-is, well, for ever."

Of course, "for ever" is a mighty long time... but I can say for certain, MSHTML is a complex body of code, and as with User32, GDI, etc., we will think long and hard about the application compatibility bar before we start thinking about rewriting that code... But, as James Bond says, "Never say never"...

It's taken me a while to wrap my head around this whole service orientation thing, and this indigo thing, and... well, everything. Reading Dare's post about Objects and Messaging I can really see how people get this stuff confused. In ObjectiveC all method calls are really sending messages (in the implementation, I believe they really do send messages)... so, does that qualify as service orientation?

Well, remember the 4 pillars of service orientation:

1. Boundaries are explicit
2. Services are autonomous
3. Services share schema and contract, not types
4. Policy based compatibility

None of these actually say that messaging is part of service orientation. Messaging is one technique to accomplish some of these goals, it isn't a fundamental tenet of service orientation.

"What excites me is the possibility that generics and other new CLR constructs as they come will also be integrated into the OS. I have not really seen any generic mechanism used at the API level in any operating system, since generics often were a compile-time feature, not a run-time feature as it is in .NET." [Wesner]

We are spending a lot of time these days debating generics in WinFX... generics will be in the CLS for Longhorn, so we are free to use them. Right now there is purely a process/engineering issue where we need to get all the various pieces together to make generics work (NGEN, C++, etc.)... obviously in the PDC build there wasn't a lot of generics, but hopefully in future releases you will see more generics in the APIs...

Martin has an interesting bliki entry on commands... we are trying to work through the design of Avalon commands internally... once we get something solid enough, I'll try to post some of the design docs...

Wesner has noticed that XAML can be used pretty broadly as a document format "If application developers start writing document-based applications that follow the Avalon model of deriving new classes from existing elements, or even simply reusing existing elements, and turning on some of Avalon's designer services, XAML could quickly become one of the most common file formats."

In fact, if you look at the container support in Longhorn (System.IO.CompoundFile, if I remember right) there is more than just XAML in here. With Longhorn we are doubling down on OLE compound files to have a good way to have complex documents with rich metadata.

Rory had an epiphany... Indigo is key. As Don says "No program is an island".

Windows and Office have often had an interesting leap frog-ing behavior, and Wesner points out that with Longhorn we are pushing the envelope in Windows...

Interestingly I think going forward we will see more innovation from application vendors - Longhorn will give developers so much more to build with that they can build much more distictive looking appliations.

For those of you that still want more... Here is the latest .NET Show, include Don and I in another reprise of the Lap...

Don & I have finished our presentation now... I did my 10 minute keynote demo (B) and then the first hour of the presentation was focused on the fundamentals (I did the talking, B-)... after lunch we did 2 hours to cover the three pillars of Longhorn (A)... overal, I guess I'd give myself a B+ rating then...

We talked with press for about 30 minutes after Bill's gig, then hung out with the delegates (attendees) for another hour or so - it was great fun. I've really enjoyed the UK gig, however I wish I had done a better job on the first hour of the talk (a B- is below what I'm willing to accept <G>)...

Anyway, tonight is the Blogger's dinner at Masala Zone - we tried to organize a pre-func at a local pub, but unfortunately we never choose a venue... looks like we will have a pretty good showing (40 comments at this point, something around 30+ people claiming they are going to show <G>)... Don's bet is we will hit around 20... still sounds like it will be a smashing good time!

As a side note - Megan (my wife) watched me present for the first time ever today. Very interesting. She's going to be at the blogger's dinner tonight also. An interesting experience to merge facets of your life like this <G>

I had a meeting at work today where I was asked to explain a bit about Avalons multiple trees, events, property system, resources, styles, etc... I didn't quite get to all of it, but I thought I'd share some of my explanation here...

Pre-reading... The Avalon rearchitecture Part 1, Part 2, and Part 3.

Trees

Avalon has One Tree, right? Well, that was what I claimed in a previous post... Of course, by now you should know that I firmly believe in the saying that "facts obscure the truth". From the view of the Avalon rearchitecture we did go down to one tree, however reality is never that clean.

Avalon as a "visual tree". That tree is a tree of objects that derive from MSAvalon.Windows.Media.Visual. Visual can be conceptually thought of as a rendering surface. In fact there are several types of visuals (2d rendering, 3d rendering, video, etc.). The base element class - MSAvalon.Windows.UiElement - derives from Visual also. Thus, the "visual tree" is a tree of visuals, some of which are also elements.

<LowLevelDetail BoredomFactor="High">
The "visual tree" is actually not really the display tree. The managed visual objects are compiled (converted, rendered, whatever you want to call it) into a "composition tree". This is built up of unmanaged "comp node" objects that are what we use for low level rendering and animation. It is these comp nodes that can animate and render at display refresh speed (yes, that means updating 60Hz+). No user code (or managed code) ever makes it to the composition tree - this is critical to maintain glitch free video and animation (not because of the GC or anything... the design of the composition tree could be an entire post...)... Communication between the composition tree and the visual tree is done through two one way message pipelines - one inbound, one outbound.
</LowLevelDetail>

Within this visual tree we needed to splice in things like a <Bold> or <Paragraph> - which can't be simply represented as a single visual (imagine a bold or paragraph that splits multiple pages). To facilitate this, we created a notion of the "logical tree" - that is a parent pointer (and children) that are not associated always with the visual hierarchy, but can have non-visual nodes in the tree.

Events

Events come in three flavors - preview events, bubbling events, and simple events.

Preview events (like PreviewKeyDown) travel down the tree from the root to the target element. Imagine if you press the key "A" inside of a textbox. The window at the root of the tree will first get the PreviewKeyDown event, followed by each element that is a parent of the textbox, until eventually the preview event makes it to the textbox.

Bubbling events (like KeyDown) travel from the target up to the root element. Again, imagine the textbox and your press "A". In this case the textbox gets the KeyDown event first, followed by each of the parents of the textbox, until eventually the event makes it all the way to the window.

Simple events (like TextChanged) only are raised on the target element. Almost all the property changed events are simple events (also called "Direct only" events).

Events are dealt with in two stages - build route, and invoke. Build route basically traces the path from the target element to the root of the tree. Then, during invoke, each element in the route is invoked with the event - either starting at the begining of the route or the end. The route will include elements from both the logical and visual tree - thus, you can handle the TextBox PreviewKeyDown event in the Bold element that is wrapped around it!

Properties

The Avalon property system - called the dependency property system - was originally designed as a way for our engineers to reuse code. We found that all of our properties wanted to share a great deal of features; inheritence, styling, change notification, attached storage, data binding, validation, etc. We didn't want to duplicate all the implementation of this for every property, so we had to find a way to make this work consistently across the platform. In addition, we didn't want the consumers of these components to have to learn a new concept, so we knew that we needed to leverage the existing CLR property system.

Dependency properties are defined with a token - the DependencyProperty - that uniquely identifies the property and lets the definer specify the various services that they want associated with that property. The definer then implements a CLR accessor for easy use. Thus, when you say "button1.Backgorund = Brushes.Red;" the dependency property system is actually invoked, and allowed to provide the implementation of that property.

This is a much more abreviated version of the discussion, but probably long enough to bore you all...

Michael Earls has stirred up a lot of responses to his plea for Microsoft bloggers to talk more about the here and now...

"Here's my point, enough with the "this Whidbey, Longhorn, XAML is so cool you should stop whatever it is you are doing and use it".  Small problem, we can't.  Please help us by remembering that we're still using the release bits, not the latest technology." -- Michael

Dare, Don, Harry, and Scoble have responded...

Michael responded to the responses...

"My plea was not so that the advanced developers of Microsoft would stop posting about new technologies, it was merely to get them to remember where we're coming from and take a few extra seconds to connect the "now" with the "next"." -- Michael

I think this clarifying point is a great one. I write my blog to talk about what I do all day, whether it is working on the house, driving at the race track, or building Longhorn. My goal in my blog is not to be a corporate mouthpiece, but rather just communicate with an entire ecosystem of people out there (of course, this could cause another round of blog-examination for me...)

Michael's comment is valid - connecting the here and now with the future is absolutely key. Not just for blogging about Microsoft and/or technology, but when talking about almost anything. One of the great skills of a presenter is to grab the audience, typically by describing the here and now, and how whatever they are talking about will move you from the here and now to a better future.

I worked on WinForms, .NET, and Visual Studio for years (well, my time in Visual Studio was mostly in the VJ++ team, which, well, anyway...) so I should spend more time talking about how WinForms, etc, contribute to the design of Longhorn... and how code and developers can migrate forward.

I don't intend to stop talking about Longhorn - it is what I work on every day (regardless of if I'm in the office! <G>) - it is part of my DNA at this point.

Interestingly CLauer thinks we develop Avalon on Windows XP... "My understanding is that the development teams that are working on WinFS, Avalon and Indigo are neccessary working on today's systems, Windows XP to name it. So, obviously, current pre-alpha builds of each of these three Longhron pilars have to run on Windows XP. I do not understand how it could be otherwise."

While the build lab does produce builds compiling on a shipping operating system (I actually don't know if they run Windows Server 2003 or Windows XP, but I think it is Win2K3?), developers run Longhorn.

If memory serves about 14 months ago it became a requirement that we dogfood Longhorn to use Avalon. For the first year or more of Avalon's existence Windows XP was the base we built on, however as we added more dependencies, and got more people using the bits, we could no longer support using WinXP as the dogfood environment, so we all upgraded to Longhorrn.

Of course, trying to develop a component and have your main dev machine be running a daily build of a pre-Beta operating system is quite a challenge. Some days you come in and upgrade to the daily build only to find that some core part of the OS decided to break that day. Of course, this is one of the ways we try to drive quality - by having the developers feel the pain if something is broken, generally it gets fixed very quickly. In addition even our VPs dogfood Longhorn, so you can imagine that occasionally there is a lot of pressure to fix something if their machines break!

The answer to the question is a little of both - we compile the new version of the operating system on both released Windows and Longhorn, but we only debug, test, and run (obviously) on Longhorn.

Sami did some DLL hacking and got Avalon running on Windows XP... I missed the post, but someone internally forwarded me that he was asking what I thought of this. I guess there are a couple points here:

Avalon is a Longhorn only feature.

One of the big new changes that isn't yet in the Longhorn builds is the new video driver model. Once that goes in, you really won't be able to run Avalon on XP. In addition when the desktop composition stuff gets turned on (it wasn't in the PDC handout build) there will be a tight dependency between Avalon and the Longhorn User32.

As with any single feature in an operating system, you can manage to get it running elsewhere. If you really wanted you could probably copy the Longhorn Kernel32 over to an XP machine, however eventually you will need to copy most of the OS over to XP to make all the features work.

Early on in the Avalon development we actually ran Avalon on XP all the time (there was no real "Longhorn" yet). For more than a year now Avalon was only running on Longhorn. Now that we are pushing towards Beta 1 the number of inter-dependencies between components are increasing.

In short, while you may have been able to get this working on the PDC build, this won't be possible in the future builds.

I guess my advice to Sami, I wouldn't bother publishing the steps needed for this. Not only is it a completely unsupported configuration, it is also something that won't work going forward.

Wes is lamenting the lack of a formal doc/view framework in Avalon... I can say that as of today we don't have plans (at least on the Avalon team) to produce a doc/view framework ala MFC (as with all statements about products these are subject to change at any time, especially with feedback <G>).

A couple key points that Wes makes:

"In MFC, we start with a full implementation of a document-based application that does nothing; all the infrastructure (opening, edit, printing, windowing, OLE, etc) is in place, and developing an application involves simply modifying the do-nothing application to do something. The best thing about this approach was that almost all the testing for the the infrastructure code came for free."

However, he continues, we took a step back in WinForms:

"In WinForms, we lost that, although there is a project underway called Genghis to restore the missing glue tying all the framework objects together into a document-based application."

Genghis creator Chris Sells (who is now a 'softie) often gives me grief for our decision not to do a doc/view framework.

At this point, it is all about resources. In Avalon we are rebuilding the core infrastructure for the presentation platform in Longhorn. We have a new driver model[1], graphics stack, control library, and application model. All of this with a unified approach allowing for integrated documents, ui, and media. This has been an amazing undertaking. Prior to PDC 2003 we had already spent over 2 years working on Avalon.

The issue is that we don't have enough time or resources to do everything, and right now the doc/view framework has fallen off of our plate (it was considered).

I've talked with people from the C++ team (that own MFC) and the .NET Client team (that own WinForms) to see if they have the resources to build a doc/view framework on top of Avalon. The nice thing about a doc/view framework (going the way that MFC did) is that it can be layered on top of a core framework. No news yet as to if they can or will do it, but we are listening to the feedback and trying to understand how we could tackle this.

"Other than the strange Objective C syntax, I found much to my liking in Cocoa. I was surprised to see support for name-value pairs, which look similar to Dependency Properties in Avalon. Cocoa does use the familiar MVC paradigm, with the standard NSController, NSApplication, NSDocument, NSWindow, NSControl objects. NSWindow, NSApplication and other "NSViews" derive from NSResponders, which implements the "Chain of Responsibility" design pattern. Even though, I have never seen Cocoa before, I know how it works because it follows the same pattern as every other framework. I know that Cocoa's NSResponder is the same as TCL's Bureaucrat, which is the same as MacApp's EventHandler."

I've spent a small amount of time programming in Objective C against Cocoa, and I also found it very elegant, but overly complex to do simple tasks. My personal believe is that MVC paradigms should always be layered on top of a simple object oriented component based framework. There is a large class of developers that don't understand MVC and you can never hide complexity completely.

"But my fear is that, while document-based applications based on Avalon may become more flashy, they will look more like web-pages and less like Office-style applications. I not getting the sense that Avalon is paying attention to the traditional document-editor application."

I disagree with your view here, but I totally understand the concern. Right now we are trying to crawl before we run. Avalon has a complete editing infrastructure with extensible mechanisms for adorners, backend stores, selection, etc. With a couple simple controls and properties you can create a editing surface for writing documents, media (animations, vector graphics, etc.), and ui (traditional forms). While we do lack the doc/view framework as an intrinsic, we are spending a lot of time trying to make sure that the platform provides the core services to allow for a great document editor...

[1] All WinXP drivers will continue to be supported, rather there is a new driver model that will be more robust, blah blah...

Don Park has an alternative to reusing the XML hierarchy for visual hierarchy for things like XAML...

We are currently having a big debate internally around the usage of Uri and String in our APIs.

Use Uri not String

URI cannonicalization and escaping is very complex and people always get it wrong, so you must have a single codebase to do the work. Beyond that, converting from each form of a URI can introduce artifacts, so once you resolve (my shorthand for canon, escape, etc.) the URI you can really never go back to a string and try to resolve again (not precisely true, but basically). In Internet Explorer the resolving of URIs was a huge source of security issues, so we can't repeat that mistake in WinFS.

Offer both Uri and String

Using a single codebase for resolving URIs is great, just don't make developers suffer by having to create URIs everywhere. Developers think of URIs as strings, not complex objects.

The pattern should look like:

class MyComponent {
    void SetSomething(string uri);
    void SetSomething(Uri uri);
    Uri GetSomething();
}

The idea being that developers can call either version of the API. The implementation of SetSomething(string) would do nothing more than new up a Uri and call SetSomething(Uri).

Use Uri not String

The problem with the above pattern is that in a component based system you have people calling components through multiple layers. If internal MSFT develoepers (and third party component developers) start calling the string version, we get back into the "string -> uri -> string -> uri" world which introduces loss of data (hence security issues).

Offer both Uri and String

We should just have a rule that says once you convert a Uri to a string, never go back. Then developers on the leaf of a component hierarchy would do the conversion, and it would transfer back.

Use Uri not String

Ahh, that is a great view, however history has shown us that doesn't work. It isn't possible to guarantee that no one converts back to a string, and therefore we will ship a bunch of components with this.

... And the debate continues to rage...

As has been mentioned many times before, XAML is a generic programming model for working with CLI object trees. Don even wrote a console application in XAML. As part of our effort to really nail down the format and rules for XAML, we are doing some internal design reviews of XAML. Right now we have assembled Gudge, Don, Rob, and myself.

The four of us came up with a long list of our pet peeves and issues (for example, using a PI for the Mapping directive makes it impossible to embed XAML inside of a SOAP message).

Rob is the program manager owner of the XAML spec, and is looking for anyone out there that has strong opinions about some of these issues to make comments on his blog... What is missing from or broken about XAML?

We gave out bits at the PDC to ellicit feedback from people, Here is an opportunity to directly spout off to the owner of the specification of XAML!

Adam Ulrich commented on my last Avalon rearchecture post:

"Mustn't controls have some inherent _general_ knowledge of their visuals?

My example: a scrollbar must know that it has some logical element that relates to visual elements that equate to a thumb, and that it can move along logical element that relates to visual elements that define some path. "

Someone once told me that facts obscure the truth (actually many people have told me that)... There are several (small number) of controls that must have deep knowledge of their visuals. The slider portion of the scrollbar needs to have knowledge of it's visuals, although the scrollbar doesn't. The scrollbar istelf is composed of a repeat button (line up), slider (which is the well and thumb), and another repeat button (line down). I don't think in the PDC builds it's quite this clean, but this 3 controls will be (hopefully! <G>) the way we build the scrollbar later this milestone.

Generally an element should have contracts with it's visuals with commands, databinding, attached properties, and named styles.

Commands are how the repeat button should bind to the LineUp/Down command on the scrollbar. Databinding allows you to bind the value of the scrollbar to the value of the slider nested within. Attached properties are used to allow the element to locate a child within - for example the ListBox looks for the ItemsControl.ContentOwner property on a child element, and that element becomes the parent for all the generated content from the list items. Named styles would be the way that you could replace sub sections of a control, this would typically only be used on more complex controls (like a data grid, or something of that ilk).

"Rich Everywhere" is a phrase I like to use to talk about Avalon. We want to enable every control to support any rich content, interaction, and presentation. Part of being rich is actually having a system that people can understand, tool, and build these great experiences on the platform.

In DOTNET the number of customization points brought about a big problem. You could customize the look of an element up to a certain point, but then you would have to completely change your programming model to use the presenter. Presenters couldn't be authored in XAML, and you weren't able to create elements dynamically inside of the presenter, so you ended up being limited to using low level drawing calls.

ECM

We had to solve the notion of "rich content". There is this tension between flexibility and programmability. For the VB developer, we want to enable something as simple as:

Dim b As New Button()
b.Text = "Hello World"

For a web developer we want to enable something as rich as:

<Button>
    <GridPanel><Video ... /><Text>Hello <Bold>World!</Bold></GridPanel>
</Button>

The problem was to do both with a single object model. We talked about having two buttons - a "simple" and a "rich" button. No. We talked about having multiple properties - "Text" and "Elements". No.

Then the idea came - borrow some pages from WinForms and ASP.NET, mix in some new twists, and viola!

ECM (I forget what the abreviation stood for originally...) was the idea to have a mechanism to take arbitrary CLR objects and convert them to UIElements. If the CLR object happened to be a UIElement, we were done. If it wasn't, then we could create a visualization for that data item using TypeConverters, ToString, or a data style. Basically that means that button now has a "Content" property, that is of type "System.Object". If you pass a string in, we stuff that string into a text element, and if you pass a GridPanel in, then we just display it.

Controls have 3 flavors - No content (Border, etc.), Singular Content (Button, etc.), Multiple Content (ListBox, etc.).

You can mix and match; a Menu has a header (Singular Content) and a list of menu items (Multiple Content) - so we have something called a "HeaderedItemsControl"...

Only use elements

When I talked about simplicity, I mentioned that we doubled down on element composition. Another side effect of this was to unify the programming model for all customization. You could now completely change the look of an element all declaratively in XAML.

Once we have this model, we now have a tenet that all controls must not have inherit knowledge of their visuals. This allows developers to completely change the look of any built in control without having to change the behavior at all.

Part of the original goals of Avalon was to leverage the power of the GPU. The idea of hardware accelerated 2D graphics has been around for a long time, but it hadn't really taken off yet (remember, we started Avalon in early 2001 [fixed date]). Today it seems pretty obvious that leveraging the GPU for 2D is the right path, but at the time that we started there was a lot of concern about the type of hardware that we would require.

One hugely controversial decision that we made early on was to write Avalon in managed code. From a platform component, the CLR is still immature. It's getting better by leaps and bounds. The work to integrate the CLR into Yukon, moving the entire system to 64-bit, and the work in .NET 1.1, and Whidbey have made the system amazing. Again, when we started .NET was just first released in beta. Also, the development teams working on Avalon are used to the C and C++ toolset that they had been working with for the past twenty years. The decision to move to managed code was a fun process, but that I'll leave for another day.

The DOTNET tree was not measuring up to performance goals. The startup time was slow, but more troubling was that the scalability of the system - the number of elements that we could create and manipulate was just too small. To acheive our goals around richness we would need a system that could scale to tens of thousands of elements, and we were only a couple thousand elements displayed in a reasonable performance. Layout was slow, working set was huge, it was a bit scary.

Before we began the rearchitecture we spent a bunch of time focusing the entire team on performance. We started doing deep analysis and looking at how the system hung together. We created two virtual teams to try and drive the performance effort - a bottoms up team that was focusing on tuning components and code, and a top down team that was looking at the design of the system to see what we could do architecturally to make the system faster. When we started the rearchitecture effort we took the data from the bottoms up and top down team as baseline data.

We had several simplifications that we hoped would contribute to better performance:

• One tree
• Simplified property engine
• CPS/DPS

One tree

By unifying the tree, we felt that for UI scenarios we would see a huge performance benefit. Specifically you would only have a single node for a element (like a Rectangle) where as before you might have up to 3 objects. Also, the connections between the elements would be much more simplified, there was no need for back pointers from the visual tree to the element tree to managed input, etc.

Simplified property engine

The original property engine from DOTNET was designed to support a very complex expression evaluation system, track dependencies, deal with complex CSS-style rules, etc. Part of the rearchitecture was the decision to cut several of these features to make the property system much simpler, and therefore (hopefully) faster.

CPS/DPS

The DOTNET layout engine, using presenters, was a single monolithic system. That system handled everything from a single absolute X,Y layout up to a complex paginated table. The issue was that for all the simple UI scenarios we were doing a ton of work for relatively no value. The solution was to create the "Control Presenter System" that would handle basic UI layout, and a more advanced "Document Presenter System" that would deal with the rich pagination and typographic layout.

By the time we finished the design for all of this we had actually completely removed the concept of presenters from the system, but the name CPS/DPS stuck for the architectural design. Funny how those things happen.

As we rolled out the architecture proposal the performance aspects of the proposal were probably the most controversial. No prototype can accurately represent how a system will behave in the "wild", and our performance team had previously heard promises of large changes helping performance. Unfortunately we were never able to get a 100% accurate measurement of the perf gains, but we had to make a decision. As with a lot of decisions, you never have all the information that you would like to have.

During the implementation and conversion to the new architecture we hit several perf snags. We didn't get any huge working set improvements (we are still working on this today), however we did achieve our scalability. The system (in our tests, no warrenties implied, etc.) scales linearly as you add more elements. The largest I've done is a couple hundred thousand elements... it was really slow, but it didn't crash.

Best performance bug: I forget the root cause, but when you ran a specific test the working set of the app would hit around 1.2GB (yes, gigabyte!) before the app would die.

We have made a couple other changes to the system since the big rearchitecture - the new styling system is one example - and we continue to try and make the system faster. The PDC bits are clearly way below what we want for performance.

The Avalon rearchitecture that happened earlier this year was motivated by several things (in my mind... hmm... another time for a disclaimer - as with anything that happens each participant will have a slightly different version of the "truth". As time goes their becomes more and more difference between each persons view. So, all that follows here is my fuzzy recollection of what happened, and shouldn't be missinterpreted to be the only "truth" of what happened...)...

• Simplicity
• Performance
• Flexibility

Before I start, I need to tell you about a few new names - DOTNET and WCP. Our old architecture bits lived in a source tree where the root name was "DOTNET". I wasn't on the team when this name was choosen, but I'm guessing that it was picked because the Avalon team was an early adopter of managed code, and so they named the directory after .NET. When we began work on the new architecture we picked a new directory name, "WCP". When I refer to WCP and DOTNET design, these are nothing more than the names of two directories in our build tree - these aren't product names, no warrenties apply, blah blah...

Simplicity

The DOTNET model had some pretty severe problems with complexity of the design. Their tended to be 7 ways to do anything, and many of them tended to be massively complex. The reason for this was pretty simple - we had 400 people working on the product and all of them were trying to build the "best" of whatever they were working on. The best example that I have is how to customize the appearance of your control... we had templating, presenters, element composition, visuals, etc... I can't remember the complete list, but at one point there were actually 7 full featured ways to customize this.

Probably the most maligned peice of technology in DOTNET was this thing called "Presenters". Presenters were a very well thought out, robust, and complete technology. Basically it was an abstraction over layout and rendering, which allowed for any control to have any display. Presenters allowed for pluggable rendering, pagination, virtualization, etc. They allowed for a clean separation between the visual tree and the element tree.

Ah, which reminds me - we had a lot of trees at the time. There was the element tree which was where your buttons and listboxes lived, and the visual tree which was the retained mode managed scene graph, the presenter tree which was a "kinda" tree that was made up of the presenters and their relationships  to their child presenters (basically an element may or may not have an element. For example, text formatting elements like "Bold" didn't have a presenter, they used their parent presenter), and we had a composition tree, etc.

Presenters where this great thing, however they were very complex to use, and they had a fairly different design center and programming model than the rest of the system.

Our solution to simplify a lot of this in WCP was to make a couple big bets - Element composition and a unified tree.

Where in DOTNET we had a separate tree for elements, visuals, and presenters - in WCP we have a single tree of nodes. For various reasons we have multiple "views" on the tree - Logical and Visual - they actually share nodes. Some people find this 1.5 tree system to also be confusing and we are still looking at ways to simplify this.

Element composition was the biggest bet by far. We are now using elements for all display composition. When you see a button in the PDC build, there are actually 17 elements inside of that button. Rectangles, Borders, DockPanels, Text, etc. Using a single feature for all rendering allowed us to remove some of the duplicate ways of customizing the display of the elements. In addition, we settled on a single styling system that included the ability to style the "visual tree" of any element.

To be continued...

The early votes are in, and it looks like people want to hear about anything besides my sump pump...

What is the deal with the MSAvalon namespace? To start, this namespace will (obviously) change. Generally we are never allowed to ship any product with any cool codename or team name in the product, so we picked this name intentionally to make it easy to remove later. Most likely MSAvalon will be renamed to "System" - the idea being that the classes that constitute "Avalon" will be in the System.Windows namespace. If you got one of the PDC namespace posters, you will notice that we actually used System.Windows on that poster.

Why did we use a namespace that is easy to replace? Because we ran out of time.

Depending on who you read and talk to, you may have heard some of the story of the Avalon team. I'm not talking about the Avalon umbrella term that we used at the PDC, but rather the group of people that work directly on the team inside of Microsoft called "Avalon". At the PDC we rolled up a bunch of teams under the term "Avalon" as a way of talking about all the great client presentation technology that a lot of teams are working on. A large portion of this work is being done directly on the Avalon team, however we have determined long ago that 99% of the populate really could care less about the organizational structure of Microsoft, so we decided to reuse the name. Fun, right?

Avalon the team was formed almost 3 years ago. It was formed by merging almost 400 people from various teams working on client presentation technologies - some people from Internet Explorer, some people from User32, GDI32, DirectX, WinForms, etc, etc, etc... a lot of people with a wide variety of opinions. As the team gelled and worked on the vision of a unified presentation platform for UI, Documents, and Media they did a lot of experiments and writing of core fundamental code.

About 2 years ago, the Avalon team really started cooking. They had a shared vision and were working hard on producing the large body of code to replace User32, GDI, etc... They began to get some internal customers (a few) and start to actually look at the developer expierence and really think about what people could do with all this great technology.

About a year ago, we really noticed some fundamental problems in the design of some of the components. We made a super hard decision to step back and do a rearchitecture of some major portions of the system. We revisited the tree model that we had, the way controls fit together, our styling system, binding, and more. The end result was a new architecture that was a more holistic view of the entirity of Avalon.

Even with the PDC on the horizon, we made a tough call to begin coding on the rearchitecture, with the goal being feature complete on the new design for the PDC. A lot of people, from a lot of teams, put in a tremendous amount of effort to get this work done in time. However, there were still components that were built on the old architecture of Avalon, and we couldn't break them with only a few months left before PDC. We decided to make the old architecture and new architecture Avalon bits run side by side - and hence we needed a namespace for the new bits. MSAvalon was born.

Once we get the last of the internal customers that depend on the old architecture bits moved over to the new architecture, we will retire the old namespace and eventually remove the DLLs from the build. After that, we can do the monster namespace change to move to the new namepsace.

It was really interesting some of the discussions that we had around this change. There were really two camps inside of the team - one said that we should ship the old architecture bits as they were more mature and had more features. The other camp said that we should push as hard as we can to give the developers at the PDC a preview of the design that we were moving forward with. There wasn't a perfect answer - the old design would show more of the intent of what we wanted to accomplish, but the new design would show more of our developer API.

In the end we decided to push forward with the new design - getting feedback from developers about our new model was determined to be the top priority. We need to hear if the explicit styling mechanism, element composition, data binding, logical tree split, etc, are usable and in the right direction.

There was amazing effort put forth by so many people to make this happen it was mind boggling. Taking a team of 400 people, and an even larger group of internal customers and partners, and making a radical design change 8 months before a public release was an amazing risk... I really hope you all feel that it was the right decision...

I still owe a code sample about using DependencyObject from a previous post (I will write that!), however I'm curious what would interest the couple people out there that read this... besides my boring opinions about the universe, and my adventures with aquatics, what do you want to read about?

1. Design issues that we are tackling for the next release of Windows (Beta 1?)?
2. History of the PDC bits (how we formed Avalon, etc.)?
3. How to code with the PDC bits?
4. Some other topic?

I'm happy to do a combination of all of the above, or skip them all... what do you care about... I just don't want to becoming boring... that would just be sad.

Sam asks "the ability to modify the rendering and content of the document on the fly?  Isn't that lost by a compile to bytecode approach?"...

Sorry for the delay in responding, Sam's post has been sitting in my inbox while I found a couple minutes to respond... There are lots of comments on Sam's post directly that respond to this, but I thought a more detailed answer might prove interesting for everyone...

First, as people pointed out there is a difference between XAML (the programming model) and Avalon (the presentation system).

Using XAML, you can invoke the parser at anytime:

DockPanel d  = (DockPanel)Parser.LoadXML("<DockPanel xmlns=\"http://schemas.microsoft.com/2003/xaml\"><Button DockPanel.Dock=\"Fill\">Hello</Button></DockPanel>");

(Appologies if the code doesn't compile, i'm not sitting in front of a Longhorn machine right now)

However - that XAML can't contain any def:Code fragments, because at this time we don't do dynamic compilation on the client during parsing.

In addition to dynamic execution of the compiler, you can also programmatically create elements:

DockPanel panel = new DockPanel();
Button b = new Button();
panel.SetDock(b, Dock.Fill);
b.Content = "Hello";
panel.Children.Add(b);

Of course, you can also set events:

b.Click += new ClickEventHandler(MyHandler);

In fact, the parser is really just doing a bunch of "new DockPanel" and "new Button" calls when it parses the XAML. XAML is just another view on code... You can do everything in code that you can do in XAML - and you can do it dynamically with a strongly typed simple programming model.

Rob is a PM on the Avalon team. He owns the XAML spec. He also is a member of the Avalon architecture team (with me and a few other folks).

Rob has a blog.

See rob blog.

Blog Rob, Blog.

Rob's first task, to do some postings that cover some of the Avalon overview presentations that he has done in the past.

Erik Arvidsson asked in a comment : "What was the reasoning for not making the UI elements extend XmlElement? Since XAML is supposed to be an XML language it would seem obvious that one should be able to use the W3C DOM."

Yet another often discussed issue internally. To start, lets consider the following markup:

<Window ...>
    <Window.Resources>
        <SolidColorBrush def:Name="MyBackground" Color="Red" />
    </Window.Resources>
    <Button Background="{MyBackground}">
        <myobj:Customer Name="Chris Anderson" />
    </Button>
</Window>

In the fabulous XML DOM I would get, of course, a bunch of nodes. The root node would be the "Window" tag, and would have children "Window.Resources" and "Button". Of course, we have already gone astray.

In XAML we recognized that properties (which can be attributes) often contain complex values (for example, the Resources property on the Window in the above example is actually a type of map/dictionary). However, sometimes they can contain simple values (like Color="Red" on the brush). Thus, you can end up with any attribute in XAML also being a compound property, which makes it a nested tag. Thus, these two are syntatically equivalent:

<Button Background="Red" />
<Button><Button.Background>Red</Button.Background></Button>

Which makes it problematic to use the XML DOM out of the box. In addition, lets flashback to that first example above - the SolidColorBrush is not actually a UIElement. While the Button and Window are both UIElements, the SolidColorBrush is just a CLR object. It would not appear in your element tree, and asking the Window or Button for it's visual children would never produce the brush. Second problem.

Finally, check out the "myobj:Customer", this is an example of a random business object (maybe a WinFS thing? maybe just something I invented) that I wanted to create in the markup. Since XAML is programming model for targeting arbitrary CLR objects, there is no requirement about the OM that these objects must implement to be serialized into the XAML (well, there are a few, but they are simple things).

Given these three things, we felt it would actually be confusing for developers if we implemented the XmlElement OM. The XmlElement OM is about traversing an XML document - the Avalon element tree can be persisted into an XML document, but it can also be generated from C#, your custom markup, or any other format that you dream up. In addition, using .NET 1.x you can serialize any .NET object into XML also - so that would argue that everything should derive from XmlElement (yes, I know that some people would applaud this! <G>).

Remember - XAML is just one of the programming models for targeting the Avlaon presentation classes.

There seems to be a lot of discussion floating around in my comments about "Dynamic XAML", which confuses me (I'm easily confused). No one thinks of "Dynamic C#" or "Dynamic VB", they are languages - it is the application that you create that has dynamic behavior...

Dynamic user interface can be easily created in Longhorn using Avalon in several ways:

1. Dynamic code
2. Conditional/Bound markup
3. Parsed-at-runtime markup
4. Projection based markup

Projection based markup

I start with projection, because I think it is what most people think of when they asked the question about "dynamic XAML". In the web world today you create projection based user interface. You do work on the server to determine what the static view the client should see (maybe with some interactivity in the form of jscript, etc.), and then you project HTML across the wire and let the (basically) dumb client render that logic.

In the web today there is this uneasy tension with DHTML (W3C DOM or IE DOM) and ASP.NET/PHP/JSP... Here you have a sever and client side programming model, both trying to produce dynamic results. You end up with this bizaree spaghetti code that spans between the tiers. You might do data filtering on the server, but allow for sorting to occur on the client to avoid round trips.

The question then is raise, with this new Windows markup "XAML", can you accomplish projection based UI? The simple answer - yes. We support parsing of markup on the fly.

However for interactivity the programming model for Avalon is .NET classes, which means you need to somehow get IL generated, or have an interpretted language. Today the JScript parser is the closest thing we have to an interpretted .NET language, but I know there are other interpretted languages out there.

Why have we not focused on interpretted or projection based UI? To put it simply - it doesn't scale. Smart client applications aren't really possible in projection based UI. If you look at any even moderately interactive application they have moved the processing logic to the client to leverage the power of the PC - Flash, Java, Anark, all do the logic on the client. Yes, there are some places that do dynamic Flash generation, but that seems to be a limitation that products like Royale and Central will solve.

Parsed-at-runtime markup

If projection based markup is only supported limitedly, then what about parsing at runtime? This is the old DHTML model of doing things like "document.Write" and "someId.InnerHtml='...'" as a programming model.

Avalon has a simple object model for our parser that will allow this type of programming. You can concat a string together, pass it to the parser, and get back a fully realized .NET object, viola!

Of course, parsing and string generation has it's problems - lack of type checking at compile time, performance, debuggability, etc. This model, like projection based markup, is supported - just not encouraged.

Conditional/Bound markup

Hopefully, eventually, I will actually hit one of these mechanisms for dynamic UI that we think is great. Well, wait no longer!

Using databinding, repeating, styling, triggers, frames, etc, for creating truly dynamic UI is the Avalon recommended way. People write "dynamic" UI today using VB.NET and WinForms that gets data from a database and presents it in a great format using DataGrids, etc. In Avalon we are evolving this and adding rich typography, template based repeating, and a new model for triggers and styling.

The nuts and bolts of this? Say that I want to create a news browser, I can create styles for the news objects (note, these are data objects, not UIElements):

<!-- Psuedo-code, I don't have a longhorn box handy right now -->
<Style def:Name="*typeof(NewsReport)">
    <DataElement /> <!-- I forget the exact name of this element... ? -->
    <Style.VisualTree>
        <DockPanel>
            <SimpleText DockPanel.Dock="Top" Text="*Bind(Path=Title)">
            <SimpleText DockPanel.Dock="Top" Text="*Bind(Path=ByLine)">
            <TextBox DockPanel.Dock="Fill" Content="*Bind(Path=Body)" />
        </DockPanel>
    </Style.VisualTree>
</Style>

Now, I could have another format for some other type of story:

<!-- Psuedo-code, I don't have a longhorn box handy right now -->
<Style def:Name="*typeof(ForSaleAdd)">
    <DataElement /> <!-- I forget the exact name of this element... ? -->
    <Style.VisualTree>
        <DockPanel>
            <SimpleText DockPanel.Dock="Top" Text="*Bind(Path=Title)">
            <TextBox DockPanel.Dock="Fill" Content="*Bind(Path=Body)" />
        </DockPanel>
    </Style.VisualTree>
</Style>

Here I could then have a listbox that contains an arbitrary list of NewsReports and ForSaleAdds, and each would be rendered according to the style - thus a WebService (or, heaven forbid!, a database) could return the content. These "data styles" can be associated with the class that defines the data structure also.

Remember The ListBox is really a generic repeating control, it isn't the same as the old scrollbar and horizontal list control. The ListBox in Avalon is more of a peer of the "DataList" in ASP.NET.

Dynamic Code

Finally, if dynamic markup doesn't solve this, you can go to the brute force traditional model for dynamic UI - write code. One of the goals with Avalon was to have a unified model that provided both a simple markup and a simple code based programming model. Thus, if you want to dynamically generate user interface elements you can simply write code like:

void ButtonClicked(object sender, ClickEventArgs e)
{
    someElement.Controls.Add(new Button());
}

Which provides you with unlimited flexibility.

Summary

My not-to-hidden agenda here is simple - dynamic applications should be dynamic on the client. The server should send data - either through web services, database access, or any other wire protocol - and the client should consume that data and generate UI. The model of a server trying to generate the correct display for a client is just broken.

My computer knows what my settings are, I don't need to server to guess them. The application on the client knows my screen resolution, DPI, color depth. It knows if I have a scanner, mouse, keyboard, tablet, printer, etc. The application on the client has full access to a powerful CPU, GPU, and hard disk that are dedicated to *me*.

We are past the world of generating static snapshots of display and blasting them down to a client. Most desktop computers you buy today have 2+Ghz CPU, >256MB of RAM, and a massive hard disk. Use them! Make your application be so engaging and productive for your customers that they want to buy it.

I'm a bit confused by the concern that Microsoft is somehow trying to threaten or take over the web with the introduction of a markup language to program Windows applications. XAML is a new programming model for the next release of Windows, code named "Longhorn". That's it.

Christopher Lord put it nicely: "One thing seems fairly clear: XAML will not threaten the web much, since the platform will only be on longhorn."

My goal is to provide the simplest and most productive platform for developers to build smart client applications on.

I've been getting hits from LonghornBlogs (which I like <G>), but I really wish my content just appeared there. I think LonghornBlogs should support an aggregation model (like PDCBloggers)...

Here are my links... Robert, can you make this happen? :-)

HTML: http://blog.simplegeek.com/categoryview.aspx/Longhorn
RSS: http://blog.simplegeek.com/BlogXBrowsing.asmx/GetRssCategory?categoryName=Longhorn

In the mean time, thanks to Andrej who keeps linking to me!

Neil says:

"People are looking for something familiar to compare XAML to, usually comparing it to XUL, since they are both XML languages for constructing user interfaces. They do have very different purposes though. XUL was primarily developed for constructing Mozilla's UI, and for constructing web oriented applications. It wasn't designed so one could write a better alternative to Microsoft Excel or Adobe PhotoShop. Thus, XUL builds on existing web technologies such as CSS and JavaScript. Web developers are familiar with these so the transition is much simpler and smoother. XAML, on the other hand, is a transition only for .NET developers since it contains things from there but contains almost nothing from the Web. The gap is much too large for web developers, which may mean that it may have trouble getting any usage by that group."

I really like the statement "It wasn't designed so one could write a better alternative to Microsoft Excel or Adobe Photoshop". Longhorn is a platform for all applications, and so the pillars - Avalon, Indigo, and WinFS - must support that large of applications being built on top of it. When we designed XAML we wanted to ensure that any scale of application could leverage the power of the platform with a simple declarative markup...

I also agree with Neil that "The gap is much too large for web developers, which may mean that it may have trouble getting any usage by that group"... this is something we are constantly concerned with. We need a platform that scales from VB to C++, from Web to Win32, from applications to documents... whenever you try to address such breadth it is always a concern that you will miss people. We are really trying to make the platform accessible to web developers, we hope to get feedback on how to do that (without making it impossible to also get the Win32/C++ devs also <G>)...

Matt (no link) comments on my styling post "Why not use CSS, instead of re-inventing it?"...

Avalon originally started with a very CSS-like styling mechanism. I say "CSS-like" because we tried to implement the syntax and rules of CSS, but not the property set. Because we made the decision to base our object model on .NET conventions, the property set for our styles needed to be the same. We didn't want "font-family" in the style, and "FontFamily" in the programing model and markup. It looked something like:

<Window ...>
    <Window.Style>
        Button { Background="Red"; }
    </Window.Style>
</Window>

We got a lot of feedback from internal customers. First, there was the complaint that this syntax wasn't XML. Secondly, there was the complaint that the CSS mechanism for dealing with namespaces was pretty nasty (using pipes). In CSS today most people don't use namespaces, but because of attached properties in Avalon (DockPanel.Dock for example) we would be using these a lot. Third was the lack of support for complex elements. Consider defining a linear gradient in XAML:

<LinearGradientBrush>
    <LinearGradientBrush.GradientStops>
        <GradientStop Offset="0" Color="Red" />
        <GradientStop Offset=".2" Color="Blue" />
        <GradientStop Offset="1" Color="Transparent" />
    </LinearGradientBrush.GradientStops>
</LinearGradientBrush>

That doesn't quite work in the CSS syntax. We where then faced with creating a syntax that wasn't XML, CSS, or anything else people had used - and didn't actually solve all the problems that we needed.

In addition, the CSS model of "rule based" styles (that is, you have a prescedence of rules applied based upon the specificity of them) was a performance nightmare. We knew that we wanted scoped styles, default styles, and massive element composition (50K elements as a goal). Very recently (earlier this year) we did a rearchitecture and part of that was switching from the CSS-like rule based style engine to the simpler explicit XML based style system.

Our goals for the new model where:

• Better performance
• Easier to tool
• Support for complex object definitions
• Unified syntax (no special parser for style)

In addition, there were several features that we could accomplish with our CSS-like approach - namely the notion of "BasedOn" styles. This is a lot like Microsoft Word's model where you can have one style inherit from another style explicitly. In CSS you can kinda make this happen by having two rules have the same sets of rules, but it isn't intuitive and it isn't really possible to provide a good tool experience.

Unfortunately we didn't fully succeed on the unified parser for style and "regular" XAML. From the developer perspective the syntax is the same, but internally we have to create FrameworkElementFactories isntead of inline elements, because the style can be applied multiple times we must provide a model for cloning the trees of elements that are defined within the style.

Which leads us to the other features - VisualTree and VisualTriggers. In Avalon the Style object (which is a CLR object) has several properties, of which VisualTree and VisualTrigger are the two most interesting for this discussion. While CSS has a huge amount of overlap with the property sets that occur in a style, there isn't a part of CSS that works for defining the visual triggers (property sets to occur when a property value or event occurs) and visual tree (the template for the display of that element). Of course, CSS attribute selectors can accomplish some of the work of visual triggers, but they don't support the event based edge triggers that we are planning in the future.

Our goal with XAML (and Avalon) was to provide a simple unified programming model for UI, Documents, and Media. This includes timelines, animation, video, controls, rich text, etc. We felt a unified approach was the only way to produce a simple understandable object model and markup.

Now, for the big pitch...

This is a developer preview. We want your feedback, we are listening to your feedback. The pushback on XUL, CSS, etc, is being listened to. I can't say that we will implement every suggestion that is given, but the entire purpose of this early preview of our technology is to get feedback from the development community. Tell me how to avoid having two languages - CSS for style and XAML for UI, tell me how to make CSS easier to tool, tell me how to make it perform and scale to tens of thousands of elements with nested style sheets... We are listening.

John Montgomery has more fun discussion on XUL...

Obviously not everyone likes what we are doing with XAML... Gerald Bauer says "Evidently working together with others to build a rich internet for everyone wasn't on the agenda."

And he also posted a mini-play:

"Act I: Ellen and Ian discuss Microsoft's Longhorn
Markup Language (XAML):

Ellen:  look at that xaml page. it's just ridiculous
Ian: you mean how much it's like XUL?
Ellen: yeah
        except that they use C# instead of js
        so if you want interactivity, it has to be
compiled
Ian: right.
jeez. wow.
could that be a bigger rip-off?
Ellen: it's stunning"

Obviously I need to look at XUL more - frankly I never have seen the XUL syntax or used it. I found the spec for XUL 1.0 over at Mozilla and saw some of the markup there...

How do I create a new custom binary behavior using XUL? I understand that in IE I am able to implement IElementBehavior and then I can create a new custom element, but I'm wondering how this works in XUL?

XAML is a simple langauge that binds to CLR objects - there is no set of "intrinsic" objects in XAML, everything is based on CLR metadata for types.

Anyway, obviously everyone will have their different views, should be a fun couple years while we all try to make progress on this stuff...

A great comment from Yves says "Have you not learned anything from CSS, HTML and the future direction of not using inline styles, but using CSS for look and feel(color, font, position ...) outside of the HTML document (or at least in the head)?"...

Avalon has a solid notion of styles. All appearance of an element can be determined from a style. Avalon styles are hierarchical - that is they can be defined at any scope an impacts from that location down in the tree. Avalon styles are not rule based (like CSS) but rather used a "named style" mechanism. Avalon styles support the definition of property and event based transformations (although I believe the event triggers aren't working in the PDC bits). First, lets look at a basic style:

<Window ...>
    <Window.Resources>
        <Style def:Name="MyStyle"><Button Background="Red" /></Style>
    </Window.Resources>
    <Button>Hello</Button>
</Window>

In this example the button *would not* be colored red. The style has a name, and therefore you would need to specify on the button:

<Button Style="{MyStyle}">Hello</Button>

The curly brace syntax means that the style is being set from a resource reference. Resources can be defined and overriden anywhere in the tree. If you have browsed the SDK documentation for Longhorn you have probably seen styles that look like this:

        <Style><Button Background="Red" /></Style>

This is what we call a "default" or "implicit" style. This requires some explanation. You see every element has a default value for every property. The default value for the "Style" property is the type of that element... OK, more explanation needed. The name of a resource can be any object, not just a string. Thus, you can actually make a resource have the name of "*Int(5)" which would be the integer value of 5 (don't try this in the PDC build, doesn't work <G>). However, one thing you can do is use a type reference:

        <Style def:Name="*typeof(Button)"><Button Background="Red" /></Style>

Ahh! So, we can use the type of an element to be the key for that style in the resource collection.

When designing the styling system we had a lot of discussion about how people would discover the default value of the style. We could have used a naming convention like "SysButton" or something else, but in the end the simplicity of using the type object from the CLR was the perfect fit. The final piece of this puzzle is that when you omit the name of style, we assume that you meant to use the type of the element that the style is for. Bingo.

OK, now that we have named the style, and have a way for elements to hook up to the style, how does a style work?

The basis of style is an "as use" syntax, that is - the content of the style should be just like the element when you would use it. This made it easy for cut and paste type operations, but also made a single syntax for people to learn. In addition, there are style specific properties you can set - like "VisualTree" and "VisualTriggers".

Before I dive into the fun of tree & triggers - one more comment about the lookup rules for resources (and therefore styles)... You can define resources at any level of the hierarchy. Including the application object. Thus, if you want to define the look for all buttons in your application you can simply say:

<Application ...>
    <Application.Resources>
        <Style def:Name="MyStyle"><Button Background="Red" /></Style>
    </Application.Resources>
</Application>

Although this is a really long winded response to Yves, I hope he can see that we haven't forgotten styling.

In comments on my brief history of XAML post there seems to be a lot of "Why don't you make XAML be pure data?"...

Purity

I used to work on the .NET Framework team, including Windows Forms and ASP.NET. There was never a debate about ASP.NET supporting inline script, it was required because they wanted to preserve the experience for ASP developers. When it came to imlementing the VS designer we all came to a reluctant decision that the "pure" way of writing ASP.NET application should be with a separate code behind file. There werre some technical reasons (we didn't have intellisense in the inline case) and there were some architectural purity arguments (shouldn't mix code and UI definition). So we shipped.

The feedback from the community has been rather vocal about this decision. There are so many times when dropping little snippets of code into the UI definition is amazingly fast and easy. In Web Matrix they made the inline code be the default.

When we started on XAML we had this same debate, and we basically decided early to side with our past experience with ASP.NET. While the architecturally pure view was to complete separate code and UI definition, the reality was that developers like to do things that aren't architecturally pure ;-)

IDs & Events

In addition to the purity argument, there is the ID and event problem. When defining some UI in XAML you often do something like this:

<Window ...>
    <TextBox ID="text1" /><Button Click="DoSomething">Click</Button>
</Window>

Then, in the code behind file you want to be able to simply say:

Sub DoSomething(sender As Object, e as ClickEventArgs)
    text1.Text = "Something"
End Sub

To accomplish this, you need to have a shared namespace (from the conceptual standpoint, not a shared CLR or XML namespace) between the code and the markup. Given that in this case the markup is defining a field in the class that will be generated you quickly want to be able to also specify the modifiers:

<!-- We don't support this yet!! -->
<TextBox ID="text1" def:Modifiers="public" />

This isn't in the builds yet, but you can see how quickly the worlds of the UI definition and the code behind begin to blur.

Commands and DataBinding to the rescue

We believe that because of the RAD aspects and the ID/Event issues that XAML should support some of these code features - however there are clearly some people that would like to have this not be the cause. Of course, you can choose not to use these features, but in addition we are working on adding features to make this separation be easier.

Commands are the ability for a component or application define a logical command that can be handled within the display tree. This means that you can create the definition of "Cut", "Copy", "Save", "PostToBlog", whatever you want (many of these are common commands that are built in). These logical commands can then be used to have a loose coupling between your logic in the code behind and the element tree defined in markup.

DataBinding is another key part. With data binding you can bind any property of any element to any property of any other object. Thus you can actually have a complete contract between your code behind and your markup implemented through a set of business objects.

While I haven't been involved in every aspect of the design and history of XAML, I thought you all might enjoy a bit of the history of how we got to where we are with XAML...

An early debate on the Avalon team was about what our markup should look like. We knew that we wanted a declarative UI model - it is actually something we have had for a long time. The Avalon team was formed with members from all over the company - User, IE, etc. And each team had a different history with markup. Obviously the IE folks had used HTML and VML in the past, while the User folks had used RC files. To add to the great debate there was also the new success of ASP.NET and their form of markup.

After great debate, we decided that the programatic object model would be based on .NET conventions. We also felt that the markup should have the same programming model as code. Neither HTML nor RC files had this "markup == object model" tenet, and it made programming difficult. ASP.NET had (basically) this model, and people seemed to really like that.

Finally we decided that the markup should be a new format that was, in fact, a persistence format for .NET objects. Thus, code like this:

Button b = new Button();
b.Text = "Hello";
b.Background = Colors.Red;

Would be transformed into:

<Button Text="Hello" Background="Red" />

Of course, that wasn't the end of the debates. Now of course, we had to decide on the object model for our objects. Should we try to make the object model familiar to Win32, HTML, WinForms, ASP.NET, or some other group of developers? There were various camps, but after the success of .NET in 2001/2 it became increasingly obvious that a WinForms/ASP.NET based object model would be the right thing for majority of developers.

Anyway, back to the markup...

The general rules for XAML go something like this:

1. Tag names are class names. The CLR namespace and assembly is discovered by an XML namespace mapping scheme (more later).
2. XML Elements are mapped to CLR properties or events
3. Sub-elements of a tag can either be other class instances or "compound" properties (of the form Type.PropertyName)

There are a few more advanced rules around the "Definition" namespace and Style.VisualTree, but basically these three rules are it. Property values are converted from strings in markup to code using TypeDescriptors (just like in ASP.NET). Rule #3 has some complications to it - there are several ways that a child object gets attached to a parent (IAddChild, IList, etc.).

There is a fourth rule:

4. The root tag of a markup file is the base type of the class the markup file defines.

Thus a file like this:

<Window xmlns="..." xmlns:def="..." def:Class="Window1">
    <Button>Hello</Button>
</Window>

Would define a new type called "Window1" that derives from "Window".

Here introduces one of our current debates - is XAML a programming language or a resource format? With XAML you can define new types, define interactivity with "def:Code", and specifiy member variables of the type using "ID". XAML also defines the UI appearance of something, and is used for localization scenarios. XAML lacks any imperitive constructs (branching, etc.). XAML is more of a "programming model" rather than a language, so we have left it at that - "XAML is a declarative programming model".

In the PDC bits their are two modes of XAML compilation - binary (BAML) and code (CAML). We are still working on analyising the two options - CAML works just like ASP.NET, it converts XAML into code (VB.NET, C#, C++, any other CodeDOM language)... BAML uses a binary format and also creates a small section of code for the parts of XAML that can't be represented in binary (like the outer class definition). CAML is the default in PDC bits, and you can use Optimization="Download" in the project file for getting BAML.

This entry is turning into a bit of a rambling mess... more later...