In a
comment, George Mladenov asked:
Why does XAML need to be (well-formed) XML in the first place? XQuery is not XML and yet it’s way better than XSLT, since its syntax is more expressive, readable, and intuitive. XAML does need to be interoperable and interchangeable between platform-independent web services. It will most probably be consumed only on Windows and (most probably) MS will come up with a XAML parser. Why does XAML need to be XML then. Why not have an expressive, readable, and intuitive syntax for doing the things that XAML was designed to do – seamlessly mixing markup with code.
I’ll respond:
XAML is XML because
We believe that making XAML be XML is the right thing to do because:
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.
4. I’m sure that there are several more reasons…
But XML isn’t Perfect
That all said, there are a number of things that we’d like to do in XAML, but XML isn’t a perfect fit.
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 –
<BUTTON>
<BUTTON.BACKGROUND>
<LINEARGRADIENTBRUSH …>
<GRADIENTSTOP Color="”White”" Offset="”0”" />
<GRADIENTSTOP Color="”LightBlue”" Offset="”1”" />
</LINEARGRADIENTBRUSH …>
</BUTTON.BACKGROUND>
Click Here
</BUTTON>
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.
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.
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.
Dare says I'm wrong on this last point. XML's goals do say that:
6. XML documents should be human-legible and reasonably clear.
So, yes, they are meant to be readable.
The issue I wrestle with is:
10. Terseness in XML markup is of minimal importance.
That impacts the writability. One example is our compact syntax versus compoundproperty syntax. I'll do a post on that question at some point.
What do you think?
I’m interested in more detailed feedback about why XML isn’t an appropriate direction for us. My brief look at XQuery after searching in the IE address bar for “XQuery Primer” brought me to this “What is XQuery?” page – it compared XQuery to ASP syntax – sounds like you are perhaps interested in mixing directives in the middle of the markup to generate content as appropriate.
We have purposely chosen not to support this concept (Response.Write in ASP, Document.Write in DHTML, etc…). We do provide a number of ways to make the content of a element tree dynamic – the primary method being DataBinding.
Everyone – let us know the scenarios that being XML enables or prevents. We’d love to hear your opinion here.