I like the description that Karsten, Tim, and Arik wrote about XAML from the What's New in the "Avalon" Community Technology Preview article:
XAML. "Avalon" also introduces XAML, a markup language to declaratively represent user interface for Windows applications, improving the richness of the tools with which developers and designers can compose and repurpose UI. For Web developers, XAML provides a familiar UI description paradigm. XAML also enables the separation of UI design from the underlying code, enabling developers and designers to work more closely together.
On top of that, I thought it would be interesting to share the 7 major goals we had in mind while designing XAML. Generally, many design decisions require balancing the different goals (as they often conflict).
Be XML
All valid XAML files must be valid XML files. The opposite isn't always true…all XML files are not XAML files. This is important because of the ecosystem of tools, systems, APIs and developers familiar with XML.
Describe Hierarchy of Objects in a Human Readable/Writable Way
Markup provides a concise way to represent a set of objects arranged in a hierarchy. It is more readable and writable than programming languages. It is the best format to represent the initial state of an object hierarchy.
Provide Page-Based Programming Model
Like DHTML + ASP.NET, XAML provides a way for you to associate programming code with the declarative markup. We recommend people having a code behind file (.xaml.vb or .xaml.cs for example.), but also support code being directly embedded inside of a XAML file. XAML and any .Net language can work together in this page-based programming model. The .Net Language needs to support CodeDOM and a set of language specific MSBuild target files. In this CTP, we support C# or Visual Basic. We will likely add J# support by spring and we look forward to supporting other languages from Microsoft (C++ and JScript) and other companies in the future.
Be Source Code or Runtime Instructions
Sometimes XAML is treated as source code, that gets compiled into an assembly (.exe or .dll) as a combination of a binary representation and IL. Other times, it is interesting to build XAML at a later time and interpret it at runtime. While we love the benefits that a markup representation give developers, we prefer to deal with XAML at compile time, not run time.
Take Advantage of Strong-Typing
Objects that have a strongly-typed OM (object model) are better systems to program with. DHTML is a system that was very string-based, and thus difficult to debug. Systems that leverage XAML (including Avalon), get the benefit of using strings in markup, but can get compile time errors for markup or code. XAML's default is that it must understand every tag and attribute. HTML defaults to ignoring any mistyped element name, attribute name or attribute value. While there is a place for this ignoring to allow for forward compatibility, we'll provide a different mechanism for this.
Be Toolable
Systems described in XAML will be creatable and consumable by a wide set of tools. We hope to have a clear & minimal set of rules on how classes get represented in markup. We hope to encourage an ecosystem of tools.
Be Useful for Much More than UI Definitions
While XAML will be heavily used in the vast majority of Avalon applications or documents, its uses will be many. I'm writing a command line tool right now that uses a vocabulary of classes in a XAML file used as data to drive the application. I'm getting the following benefits over just using XML to represent this data: 1) validation of my data file without having to write a schema and using a validating xml reader; 2) my code that needs to interact with this data, does it in a strongly typed way; Intellisense works in my code behind; 3) my system has built in extensibility, instead of being tied to specific tag names, I'm tied to a specific class (and subclassing allows others to provide other specializations of that class.) 4) etc… (When this tool is done, I plan on sharing it)
Don't Forget Why We Built XAML - Avalon!
That all being said, I believe it is important to remember that for as interesting as XAML itself may be to some, we are building a comprehensive platform with Avalon. Some people blog excitedly about XAML…however, many of them are actually discussing the power of Avalon, not XAML. XAML is a way to use declarative markup with a set of CLR classes. We're investing much more R&D in the Avalon API and Avalon infrastructure than we are in the parser and markup compiler.
Some Related Previous XAML Posts
Why is XAML well-formed XML? (Rob Relyea)
XAML vs. Serialization (Chris Anderson)
MarkupCompilation: XAML, BAML, .g.cs Details (Rob Relyea)
When are IDs necessary in XAML & what about ID=“Root“? (Rob Relyea)
Is it bollixed up? (Chris Anderson)
New XAML Terminology (Rob Relyea)