Declarative Markup and Code Syntax in XAML

"XAML doesn't do math", our instructor said yesterday. I'm taking part in a three-day training in Windows Presentation Foundation (WPF), a new user interface framework from Microsoft; and the Extensible Application markup Language (XAML) declarative markup preferred by WPF. The instructor was trying to point out that XAML separates a declarative representation of user interface setup (using XML) from the business logic of the application (in C# partial classes). But how often is that likely to last?

While there are benefits of declarative application specification, and XML brought order to the markup landscape by rigorously specifying a common syntax, XML is not the hammer for every nail. Most apparent, it is much too verbose for declarative definitions. Here's an example from Microsoft's WPF Data Binding Overview:

<Binding Path="StartPrice" UpdateSourceTrigger="PropertyChanged">
  <Binding.ValidationRules>
    <ExceptionValidationRule />
  </Binding.ValidationRules>
</Binding>

The WPF designers realized that some things would have been much too verbose for XML, so they created their own internal syntax (negating the benefit of XML). Here's an example (from today's presentation) of the new syntax you'll need to learn:

Value="{Binding RelativeSoure={x:Static RelativeSource.Self}, Path=(Validation.Errors)[0].ErrorContent}"

Obviously this is nothing like XML, for good reason. XML just couldn't meet the need. I've come to realize that XML shouldn't even be used in the first place for declarative markup. (More on this in another post.)

If the evolution of XAML is anything like that of JSP and JSF, code will soon start appearing in the declarative markup. JavaServer Pages (JSP) and JavaServer Faces (JSF) similarly started out trying to use XML as a declarative markup. JSP made the mistake of allowing Java snippets to be embedded directly within the presentation pages. JSF took a different route: recognizing that XML was too verbose, an entire expression language was created. Eventually this expression language was unified between JSP and JSF, and you can embed all sorts of complicated object access and calculations within the declarative markup.

I wouldn't be surprised if the custom syntax used by binding will soon be expanded to meet other needs. Eventually complicated object access will be added. (You can already see the [0] operator in the syntax above.) Simple mathematical expressions will then come next, coupled with LINQ expressions. XAML will soon do math.

WPF will soon do code. Then every amateur programmer will start sticking entire routines and then classes in their XAML. What used to be simple XAML (if it ever was simple) will soon be a hodgepode of XML, custom expression syntax, and procedural logic.