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...