Robin Berjon

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.

This article is part of a series on XML Bad Practices.