Summary: A Call to XAML
SeeAlso: GettingStartedWithXAML

A few initial thoughts. Wiki it up: jump in the pool, the water is fine.

The real problem is that Microsoft still hasn't defined a clear strategy for XAML. Obviously its key reason for being is for creating Avalon ""UIs"" declaratively, but it can do so much more. -- DrewMarsh

Rumors

Okay, some MVP (who shall remain nameless) just said that XAML will be in Orcas. That sounds wrong to me. Did he-who-shall-not-be-named misspeak? -- StuartCelarier

Notes toward an XAML Manifesto

Declarative Aspect of XAML

Declaratively construct any graph of objects.

The value of declarative code; the drawbacks of declarative code.

Non-Avalon Aspect of XAML

Don Box writes: "XAML is domain-neutral, so while it may be used to create desktop apps, web pages, and printable documents, it could also be used to create CRM apps, blogging backends, or highly concurrent web services provided you had a supporting CLR-based library to do the heavy lifting." #

See Drew Marsh's blog entry Here's Your Chance To Help Shape XAML's Future

Avalon Aspect of XAML

Separating user interface functionality from user interface design.

Don't make designers use programming tools.

Don't let software engineers design.

The declarative nature of graphic design.

Why styling a la CSS didn't cut it.

Discussion

IMHO, this question is answered by considering the three previous questions. CSS is good at separating ui functionality from design, or model from view, but is a hard model to tool, it is a hard model for software engineers to understand, and it is poor for real graphics design.
With Avalon we are trying to move to a model where a graphics designer, a guy who uses Illustrator or PhotoShop currently, can be directly editing the application UI alongside the software engineers developing the interaction and backend business logic. We need a style mechanism that:

1. lets the designer "draw the ui"
2. where in the WYSIWYG view it is relatively clear why one button is blue and another is green.
3. And BTW, it would be nice if you could parse it with standard XML tools

CSS does not address 1. It is not a compositional styling model in the sense that Avalon VisualTrees are. You can specify properties of a Button, but you cannot change the components of the Button (Rectangle, Text, etc.). You could imagine extending CSS to do this, but we feared creating a "almost-CSS" that made no one happy.
As far as 2 goes, the CSS selector mechanism makes it almost impossible to tell why a particular property with a given value without inspecting the rules, hard to do in a WYSIWYG tool. Contrast this with the Word style model, where you can inspect the Style property of a range of text, then look in a dialog at the values of that Style. This is a much more toolable model, so we tried to adopt it. The result is Styles with Names, and the ability to Base one Style on an existing Style, again by name. We did end up with one remaining set of rules, those for applying Style by Type...thus the def:Name="*typeof(Button)" syntax.
Finally, when we had this set of semantics, without the Selector language of CSS, it was pretty easy to express in XML, which was a nice plus.

-- JohnGossman

Stolen Apples

ChrisAnderson blogged

...XAML is really just a way to persist a set of CLR objects (of course, a specific set of objects with a specific grammar... not to be confused with a general purpose serialization engine... )

MarkusKohler blogged on the similarities between XAML and Ant. Hmmm...

MarcClifton's blog is entitled MyXaml et al. (is the "My" designation a symptom of residual scarring from VB? "": )"".

---

Comments

""The original (now changed)"" jumping off points all seem to be very tightly tied to using XAML for creating Avalon user interfaces. Is that the specific target of this discussion? -- DrewMarsh

No, not the target, just the initial motivation (from another discussion) so I thought I'd jot them down before I lost the inspiration. Hence the overly vague "Notebook" label. -- StuartCelarier

I understand Drew's concern here. You could probably call this:

1. XAML for UI Manifesto; or
2. Avalon Markup Manifesto; or
3. ?

We don't have a great name for using XAML with Avalon Elements. We will. Start with one of those choices, or propose your own idea. -- RobRelyea

I was hoping this (1) would expand to a broader discussion, and (2) engage a few Microsoft minds on the wiki. Clearly #2 was successful (Hi, Rob! "": )"", perhaps we can work on #1. -- StuartCelarier

MS-XAML Is Neither Generic Nor Domain-Neutral

MS-XAML is not a generic serialization format; it is specifically designed for Avalon based object graphs, and does not work well with general purpose object graphs :(. This is the issue Marc Clifton and Frank Hileman (myself) have been trying to bring to the attention of all developers, as it affects everyone trying to use MS-XAML as a general-purpose serialization format.

The first major isssue is the serialization of properties:

1. As you would expect, often an xml element represents an instance of a class.
2. Not all properties of classes can be represented as inline text attributes in the xml element, so we need some sort of xml sub-elements for those.
3. But ordinary xml child elements cannot be used to represent property values. By "ordinary", I mean elements that use the property name as the tag name.
4. This is because Microsoft chose to interpret child elements as children objects of the parent object. So if you have serialized an Avalon-based object graph, child elements are implicitly assigned to the Child property or Children collection of the parent object. If you did not serialize an Avalon-based graph, you have no Child/Children. Guess what? You are now "screwed" -- read on.
5. Because the implicit Child/Children assignment has stolen the most intuitive, natural syntax for property values, Microsoft had to come up with some other syntax for properties. The syntax chosen was the "compound property syntax", consisting of the class name of the object containing the property, a dot (.), and the property name. For example, "<Button.Background>".
6. The compound property values go right in the xml hierarchy at the same level as the Child/Children. So if the compound property syntax is not confusing enough, the mixing of children and compound properties at the same level is sure to finally confuse the reader. Add compound properties representing collections and see a real mess.

I ran into the problems above as soon as I tried to use the MS-XAML syntax for a non-Avalon object graph, namely, VG.net vector graphics . The results were not pretty. Marc ran into the same problems trying to use MS-XAML to serialize Windows Forms object graphs. This was the motivation behind MyXaml . MyXaml is an attempt to create a clean, generic XAML, that works well with all object models, not just Avalon. The "My" prefix was inspired by MySql, which has a similar open-source license.

Why the implicit Child/Children assignment in MS-XAML? One possible reason is the decision to use the Decorator pattern extensively in Avalon in place of ordinary property values. For example, if you wish to make text bold, you can use a Bold decorator, instead of a Bold property. To add a transformation to a graphical object, you insert a transformation decorator in between the object and its parent. An implicit Child assignment hides some of the complexity of the Decorator pattern. Getting rid of the Decorator pattern would have simplified the xml as well.

The second major problem with the MS-XAML format is parser complexity. You cannot write an MS-XAML deserializer simply by following the rules roughly outlined above for object values and property assignments. For example, a visual tree in MS-XAML looks like an object graph, but it is not -- a whole new parser is required. It is also possible to cram object creation and sub-property assignment into xml attributes using yet another syntax and parser.

-- FrankHileman