XML Bad Practices
XML for Cyborgs
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
element that
actually "talk" to its parent, in this case Canvas.Top
and
Canvas.Left
).
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
Rectangle.Fill
even though it contains a complete image, should the rectangle itself be a property of the
canvas
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.