George Mladenov asked
Why does XAML need to be (well-formed) XML in the first place?
To which Rob Relyea responds with the following reasons
1. Without extra work from the vendors involved, we’d like all XML editors be able to work with XAML.
2. We’d like transformations (XSLT, other) be able to move content to/from XAML.
3. We didn’t want to write our own file parsing code, the parser code we do have is built on top of System.XML.XmlTextReader. We are able to focus on our value add.
Thus it looks like XAML's use of XML passes the XML Litmus Test, specifically
Using XML for a software development project buys you two things (a) the ability to interoperate better with others and (b) a number of off-the-shelf tools for dealing with format. If neither of these things apply to a given situation then it doesn't make much sense to use XML.
However there are tradeoffs to using XML, some of which Rob points out. They are listed below with some of my opinions
1. We want to enable setting the Background property on a Button (for example) in one of two ways:
a. Using a normal attribute - <Button Background=”Red”>Click Here</Button>
b. Using our compound property syntax –
...
c. Ideally if somebody tried to use both syntaxes at the same time, we could error. XML Schema – as far as I am aware – isn’t well equipped to describe that behavior.
Being the PM for W3C XML Schema technologies in the .NET Framework means I get to see variations of this request regularly. This feature is typically called co-occurence constraints and is lacking in W3C XML Schema but is supported by other XML schema languages like RELAX NG and can be added to W3C XML Schema using Schematron annotations. Given the existing complexity of W3C XML Schema's conflicting design goals (validation language vs. type system) and contradictory rules I for one am glad this feature doesn't exist in the language.
However this means that users who want to describe their schemas using W3C XML Schema need to face the fact that not all the constraints of their vocabulary can be expressed in a schema which is always the case it's just that some constraints seem significant enough to be in the schema while others are OK being checked in code during "business logic processing". In such cases there are basically 3 choices (i) try to come as close as possible to describing the content model in the schema which sometimes may lead to what us language lawyers like to call "gross hacks" (ii) use an alternate XML schema language or extend the W3C XML Schema language in some way or (iii) live with the fact that some constraints won't be describable in the schema.
It is a point of note that althogh the W3C XML Schema recommendation contains what seems like a schema for Schema (sForS) (i.e. the rules of W3C XML Schema are themselves described as a schema) this is in fact not the case. The schema in the spec, although normative is invalid and even if it was valid still does not come close to rigidly specifying all the rules of W3C XML Schema. The way I look at it is simple, if the W3C XML Schema working group couldn't come up with a way to fully describe an XML vocabulary using XML Schema then the average vocabulary designer shouldn't be bothered if they can't either.
2. It is a bit strange, for designers or developers moving from HTML to XML. HTML is forgiving. XML isn’t. Should we shy away from XML so that people don't have to quotes around things? I think not.
Having to put quotes around everything isn't the biggest pain in the transition from HTML to XML, and after a while it comes naturally. A bigger pain is dealing with ensuring that nested tags are properly closed and I'm glad I found James Clark's nxml-mode for Emacs which has helped a lot with this. The XML Editor in the next version of Visual Studio should also be similarly helpful in this regard.
The lack of the HTML predefined entities is also a bit of culture shock when moving to XML from HTML, and one some consider a serious bug with XML, I tend to disagree.
3. It is difficult to keep XAML as a human readable/writable markup, as that isn’t one of XML’s goals. I think it needs to be one of XAML’s goals. It is a continual balancing act.
Actually one of the main goals of XML is to be human-readable, at least as human readable as HTML was since it was intended to replace HTML in the beginning. There's a quick history lesson in my SGML on the Web: A Failed Dream? post from earlier last month.