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.