Some XML languages are clearly designed to match a processing approach or a data model, and are unfortunately later pitched as intended for human consumption. There are many such examples, and they tend to exhibit several of the errors examined in this series. XAML is a very obvious example of this, but unfortunately it is such a verbose language that there would be no room here for an example of just how mind-boggling it can be. A quick display of one of its bizarre traits should suffice. Here is some very simple XAML:
The above shows two things: compound properties (the
Rectangle.Fill that is a child
element acting as if it were
an attribute of its parent but with extra structure), and attached properties (attributes on an
actually "talk" to its parent, in this case
There is no doubt that there is a logical model behind this approach, but it belongs to the
implementation that supports it, and makes things complex for the user. Indeed, how am I to know
that the position of a rectangle is a property of its container, and not something intrinsic
to it? Likewise, why is the fill of a rectangle a property with the name
even though it contains a complete image, should the rectangle itself be a property of the
and be called
Canvas.Rectangle? The only answer that comes to mind is "Come with me
if you want to live".
That is the sort of issue that arises when the underlying model is made too explicit in the language.