I have recently been dabbling with WPF (Windows Presentation Foundation) Microsoft’s new graphics framework for building Windows applications that is at the core of Windows Vista. The framework is a departure from the likes of previous frameworks such as MFC and .Net 2.0 WinForms that treated the screen as a canvas that is sub-divided into rectangular regions. Each region is owned by a piece of logic, usually a graphical control that would be responsible for drawing and creating the content for that region. Buttons are responsible for drawing themselves, windows for drawing their surrounds and menus know how to drop down or pop up. As a general rule each area of the screen was owned by one control, the drawing of rectangular regions could not overlap. These limitations were fine in the days when processing resources were limited. It was optimised to work out what regions to draw and redraw as users interacted with the computer.
With WPF a complete re-think has occurred. Essentially WPF is based upon the concept of a graphics tree, a tree of graphical objects arranged in a hierarchy. The tree is treated in a declarative manner where each graphical element describes itself e.g I’m a rectangle, this big, with this fill colour and border. WPF has been designed to take advantage of the graphics cards that are includes in the majority of PCs. All WPF graphic display is done via the Direct X graphics engine. The WPF graphics tree is converted into a Direct X graphics tree. That’s it.
In order to program WPF Microsoft have helpfully provided a .NET library. You can develop applications in your favourite .NET language, there is a beta extension to Visual Studio 2005 for this. Like any good IDE and tool-set Visual Studio provides a graphical editor for creating .NET WPF applications, windows, dialogs and controls. I’m sure you are all familiar with the standard drag and drop style of interface where you compose windows via the layout of graphical components.
Ok now here is the rub. Some of you may already be familiar with .NET 3.0 and WPF and you maybe wondering why I haven’t mentioned XAML (Extensible Application Markup Language). The reason I haven’t mentioned XAML is that it isn’t fundamental to developing applications in WPF. However, according to some folks WPF is XAML. The use of XAML is yet another example of the misapplication of XML in the development of software. The industry is fixated in the use of XML for everything, when in the majority of cases it is totally the wrong thing to do.
Starting with WPF/XAML and a few other examples I’ll explain why. In so doing the next time you think XML is cool, take a moment to reflect.
When developing applications in Visual Studio for WPF the tool helpfully creates the XAML definition for the window say that you have just created. There are tags for buttons <Button>, applications <Application>, menu items <MenuItem> etc. Each tag corresponds in fact to a class in the WPF framework. To create a button with the text ‘OK’, you use the following <Button>OK</Button>. You get the idea. When you compile and execute the application Visual Studio helpfully provides a code generator that creates .NET (usually C# code) from the XAML definition.
Sounds fine? Well not exactly. Not exactly because XML, even with validating parsers, is not semantically rich enough to capture the constraints of the WPF framework. For example nested menu structures are created in XAML using the <MenuItem> tag. Here is an example of a nested menu.
<Menu VerticalAlignment="Top" HorizontalAlignment="Left"
Height="20" Width="50" >
<MenuItem Header="New" />
<MenuItem Header="Open" />
<MenuItem Mode="Separator" />
<MenuItem Header="Database" >
<MenuItem Header="Delete" />
<MenuItem Mode="Separator" />
<MenuItem Header="Exit" />
You can create tabbed windows in a similar way with the <TabItem> tag. I wanted to create a two level tabbed window, so thinking it behaved like the MenuItem I created a similar structure to the menu above. The XML parser didn’t complain. It was only when I came to debug the application that the code generated from the XAML reported an error. Apparently TabItem can’t be nested in the way I intended. You need an intermediate control, such as a TabControl, between nested TabItems.
So this got me thinking, what is the point of having XAML in the first place? It doesn’t provide the semantic richness required and it introduces that awful XML tagged syntax, you can’t see the wood for the tree. In fact in the previous version of .NET 2.0, the graphical editor for WinForms worked in a similar manner. It creates a resource file, not in XML, that was compiled into code. WPF would work a lot better if Microsoft hid the XAML, created a proper language with real keywords that was both expressive and powerful. XML appears to have been chosen because XML is cool and not that it is an appropriate choice of technology for the problem to be solved.
XSLT is another example. Here is a declarative language for transforming XML from one format to the other. The basic language contains approximately 35 keywords, small by programming language standards. What did the wonderful people defining the language decide to do, they decided to use XML as the syntax of the language. What a mistake, it is impossible to read, edit and maintain. A simple syntax using keywords instead of tags for the language would have been much better. Why the fixation on XML?
Finally a few months back I was working on a small project which required the transfer of a complex nested data structure with cyclic references between a Windows .NET C# environment to a J2EE Java environment. Naturally the engineers with whom I was working decided to adopt XML. Various strategies were adopted for the XSD to accommodate the cyclic references (I won’t go into them now). Both the C# and Java environments provide tools for binding to XSDs and therefore allowing the serialisation and de-serialisation of XML documents to be performed. Could we get data to be transferred between the two, bi-directionally, well no? It transpired that there are many different ways to interpret the XSD when binding, list structures and references are problematic. After two weeks of banging our heads against the wall and in frustration, we decided to write a very noddy CSV (de-)serialiser that used reflection to transfer the data between the two environments. It worked like a dream, was very fast and didn’t cause code bloat. It only took us three days to complete, we got the job done much quicker.
So the morale of all this is, if you have a hammer not everything is a nail. The world has gone mark-up language crazy. I’m waiting for the world to wake up and realise that XML was a bad idea and that how we used to do data transfer about eight years ago is more appropriate, that is thinking explicitly about the semantics and encoding. You can see this with WSDL and web-services. Application integration, especially SOA, requires efficient inter-application communication. WSDL allows bindings to non-XML transport structures. Most Web Service vendors including Microsoft have discovered that it is much more efficient to build systems that don’t use XML. Microsoft’s Windows Communication Foundation (WCF, formally Indigo) supports non-XML bindings for the implementation of web services.