16

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.

Community
  • 1
Roman Starkov
  • 4,469
  • 3
  • 31
  • 38
  • 3
    Yes, it can be parsed by an XML parser, but not meaningfully / completely. For instance, it uses string attributes to define data sources and property mappings. – Konrad Rudolph Mar 12 '12 at 18:27
  • 5
    What do you propose as an alternative? Any discussion about the suitability of a particular technology would have to address suitable replacement technologies. – Robert Harvey Mar 12 '12 at 18:42
  • 2
    XAML is not without counterparts, you know. XUL, Glade and QML are all based around the same idea. I think you're singling XAML out unfairly. – user16764 Mar 12 '12 at 18:57
  • 1
    XAML might not be as much of a subset of XML as you think. Check out the "Differences between XML and XAML" paragraph here: http://itorian.com/articles/silverlight/tutorial/What%20are%20XAML%20and%20XML.%20Why%20we%20use%20XAML%20in%20Silverlight%20and%20WPF/Default.aspx – CFL_Jeff Mar 12 '12 at 19:26
  • This question is being discussed on [Meta](http://meta.programmers.stackexchange.com/questions/3308/why-was-the-xaml-question-closed). – yannis Mar 12 '12 at 19:32
  • 1
    @RobertHarvey I mentioned a "custom-designed domain-specific language" as an alternative. XML is general enough to represent anything, but we build custom languages for many things. – Roman Starkov Mar 12 '12 at 19:38
  • 1
    @CFL_Jeff All XAML is valid XML, but not all XML is valid XAML, therefore XAML is a proper subset of XML. No? – Roman Starkov Mar 12 '12 at 19:40
  • A custom-designed domain-specific language would have to fulfill the [7 goals for XAML](http://blogs.windowsclient.net/rob_relyea/archive/2009/05/28/our-7-goals-for-xaml.aspx) – Robert Harvey Mar 12 '12 at 19:57
  • 1
    @RobertHarvey Aren’t you curious yourself why "Be XML" is a goal by itself? Why was it a goal for XAML but not, say, C#, which can surely also be represented as XML (shudder). – Roman Starkov Mar 12 '12 at 20:18
  • They apparently figured that the benefits outweight the disadvantages. However, if that constrains your analysis, just remove that goal. C# can be represented in a multitude of different ways; there are serializers for XML, JSON and binary, and it would be simple enough to roll your own. – Robert Harvey Mar 12 '12 at 20:19
  • @RobertHarvey Shame that questions about whether that decision (XML benefits outweigh drawbacks) was erroneous are somehow unconstructive. – Roman Starkov Mar 12 '12 at 20:41
  • 1
    @RobertHarvey: You misunderstood what romkyns meant. You are thinking of serializers that can serialize .NET objects, he is talking about C# source code. – Timwi Mar 12 '12 at 21:25
  • 3
    I think that the biggest benefit of XAML is not that it can be parsed by XML parsers. It rather is that XAML is similar to XML, and most developers already know how to work with XML, and so learning curve is much less steep. – Juozas Kontvainis Mar 15 '12 at 07:32
  • 2
    @JuozasKontvainis If by "work" you mean "parse it in their tools" then yes. If you mean "write a UI described by it" then the familiar syntax might look like it helps, but realistically, you still need to learn what to put inside attributes (because that isn’t XML), and that is by far the hardest thing, in my personal experience. Learning a new syntax, especially if it’s simple and well-designed, is trivial, in my opinion. – Roman Starkov Mar 15 '12 at 10:13
  • @Timwi I wasn’t talking about C# source code; question rewritten to clarify. – Roman Starkov Mar 15 '12 at 10:13
  • 1
    @RobertHarvey I’ve updated the question quite a bit. Yes, the designers considered the benefits and drawbacks of XML and decided it’s worth it. I’m asking whether this decision was correct, because for me personally deriving the langauge from XML did not seem to bring any advantages. That’s what prompted the question. – Roman Starkov Mar 15 '12 at 10:18
  • @romkyns, revised question is much better. I'd still claim that not having to learn basics is the biggest advantage. Developers familiar with XML can focus on learning framework concepts, instead of having to learn syntax at the same time as framework concepts. – Juozas Kontvainis Mar 15 '12 at 11:45
  • 1
    XML is a fine generic markup language. The mistake is when people persist in using it for things that aren't markup. – comingstorm Apr 17 '12 at 17:09

3 Answers3

4

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

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 3
    Would you agree that the same reasoning applies equally well to things like, say, YACC grammar descriptions, TeX, regexes, Verilog and maybe even LISP? We came up with special syntax for each one of these. They would benefit in the same way you list in the first paragraph. Then doesn’t it follow that using XML for them would be the right thing, because XML meets the goals you mentioned? – Roman Starkov Mar 15 '12 at 22:53
  • Only XML is widely recognized as a universal data meta-standard, from which you can create as many individual data standards as you wish. To avoid muddying the waters, I have removed the first paragraph. – Robert Harvey Mar 15 '12 at 22:56
  • S-expressions never caught on as a metadata standard, maybe because nobody like all those silly parentheses. Ubiquity is the compelling factor here; all of those alternate syntaxes you mentioned can be represented in XML, if you're so inclined. – Robert Harvey Mar 15 '12 at 22:58
  • 2
    All of them can be represented in YAML and JSON too (and vice versa). – Timwi Mar 15 '12 at 23:21
  • OK. Which of those (if either) is widely recognized as a standard for building standards? Are they widely recognized as meta-standards in their own right, like XML is? YAML claims it is a data serialization standard; JSON says it is a lightweight data interchange format. If you're not creating a standard of some sort, but merely need a lightweight mechanism for transferring data, YAML or JSON might actually be a better choice. – Robert Harvey Mar 15 '12 at 23:28
  • 2
    One huge problem I see throughout this argument is that XAML isn't really data. Sure, it could just be treated as just an object graph, but this kind of thinking is probably why a lot of people don't like it and why it has such a learning curve. "hey lets go make an object graph, er, I mean a user interface". I have no idea how it could be made better, but I'm confident it could be. – Earlz Feb 18 '13 at 15:29
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.

benzado
  • 2,293
  • 17
  • 23
  • 1
    I do like XML; I just don’t like writing it by hand. 1. Yes, they ought to, but alas the reality is that Visual Studio can’t really pull that off. 3. This is orthogonal to the discussion of whether XAML was, in hindsight, a bad idea. Yes, one could, but why would one _need to_ if XAML was not a bad choice? – Roman Starkov Apr 03 '12 at 08:51
  • 1
    My point is that you are judging it entirely against the criteria of writing it; your concerns have to be balanced against validating and interpreting it too. A DSL that was nicer to write would almost certainly be harder to parse. But an intermediate compilation step could give you the best of both worlds. – benzado Apr 03 '12 at 12:16
0

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.

John Henckel
  • 239
  • 1
  • 9