In hindsight, is basing XAML on XML a mistake or a good approach?

Question

XAML is essentially a subset of XML. One of the main benefits of basing XAML on XML is said to be that it can be parsed with existing tools. And it can, to a large degree, although the (syntactically non-trivial) attribute values will stay in text form and require further parsing.

There are two major alternatives to describing a GUI in an XML-derived language. One is to do what WinForms did, and describe it in real code. There are numerous problems with this, though it’s not completely advantage-free (a question to compare XAML to this approach). The other major alternative is to design a completely new syntax specifically tailored for the task at hand. This is generally known as a domain-specific language.

So, in hindsight, and as a lesson for the future generations, was it a good idea to base XAML on XML, or would it have been better as a custom-designed domain-specific language? If we were designing an even better UI framework, should we pick XML or a custom DSL?

Since it’s much easier to think positively about the status quo, especially one that is quite liked by the community, I’ll give some example reasons for why building on top of XML might be considered a mistake.

Basing a language off XML has one thing going for it: it’s much easier to parse (the core parser is already available), requires much, much less design work, and alternative parsers are also much easier to write for 3rd party developers.

But the resulting language can be unsatisfying in various ways. It is rather verbose. If you change the type of something, you need to change it in the closing tag. It has very poor support for comments; it’s impossible to comment out an attribute. There are limitations placed on the content of attributes by XML. The markup extensions have to be built "on top" of the XML syntax, not integrated deeply and nicely into it. And, my personal favourite, if you set something via an attribute, you use completely different syntax than if you set the exact same thing as a content property.

It’s also said that since everyone knows XML, XAML requires less learning. Strictly speaking this is true, but learning the syntax is a tiny fraction of the time spent learning a new UI framework; it’s the framework’s concepts that make the curve steep. Besides, the idiosyncracies of an XML-based language might actually add to the "needs learning" basket.

Are these disadvantages outweighted by the ease of parsing? Should the next cool framework continue the tradition, or invest the time to design an awesome DSL that can’t be parsed by existing tools and whose syntax needs to be learned by everyone?

P.S. Not everyone confuses XAML and WPF, but some do. XAML is the XML-like thing. WPF is the framework with support for bindings, theming, hardware acceleration and a whole lot of other cool stuff.

Answer 1

The only compelling reason to use XML is to establish an open data standard. XAML is the same display language used in both Silverlight and WPF; any vendor can use the same markup standard to create a display definition for their own platform, and it can be reused in Silverlight or WPF.

In the aerospace industry, we have control rooms that, thanks to the advances of computer technology, are now reasonably flexible. In the past, all the hardware was custom, unique, and very expensive; today it is all run with inexpensive, commonly-available, off-the-shelf PC's. This greatly reduces vendor lock in. However, display widgets are still written using ActiveX, because that's how it's always been done.

ActiveX requires access to Microsoft tools that are, well, obsolete. So the Air Force and the Inter-Range Instrumentation Group is coming up with a Data Display Markup Language, which is XML based. This will allow practitioners to design displays using XML markup, in the editor of their choice. Sound familiar?

Nobody argues that XML is not without its faults. But it's the best thing available for what it was designed to do, until something better comes along.

See Also
Why XML Doesn't Suck

Answer 2

Your objections to XML have nothing to do with using it as a GUI description language; they are all complaints about working with XML syntax that apply equally to any form of XML.

So it sounds like you just don't like XML.

You're right, it may not be the optimal choice for editing by hand, but for a GUI description language I'd make some counter-arguments:

1. (IMHO,) GUIs are graphical and ought to be laid out graphically. The file format isn't really that important, because you really shouldn't be editing it by hand. (Text-based is nice for source-control's sake, but verbosity isn't a problem.)

2. Besides the parser being available, XML is also easy to validate: you can write a DTD or XML Schema and then use generic tools to tell you if your file is legal. This is going to be very useful for a GUI description language. Doing the same in JSON or YAML isn't as straightforward.

3. If you're really unhappy with writing XAML directly, there's nothing preventing you developing a new format and then compiling that into XAML. For example, you could come up with a straightforward mapping from JSON to XAML, so you can have its JSON's lighter syntax (and the ability to comment-out attributes), and then generate the XAML when you build your app. People rarely write HTML directly any more, but HTML is still a great format.

Answer 3

This question is subjective, so I think it is fair to post an answer that is based on my personal preference.

XML is hard to read. For example, open this link and click "Sample" to compare XML and YAML side by side. The latter is clearly much more human readable.

If you want to use XML to describe a GUI, then you better be damned sure that you provide sufficient tools so that humans will not have to look at the XML.

Clearly XPF has failed in that regard.