I sometimes wonder if the world is turning into a globe of pansies when I read statements like "I can't blog that because it would appear as if I am attacking competitors."  Geesh.  What is wrong with attacking competitors?  The world is not an Olympic and the market is not some field-and-track sporting event where you are competing side-by-side.  Get in touch with your inner feelings and kick your opponents between the leg in earnest.  When they are down, kick them again so they can't get up.  Nasty?  I call it being sincere.

Certain design patterns are more compelling than others.  Some patterns are outright mesmerizing.  For example, the Hierarchy by Containment (also known by many other names) pattern,  which represents hierarchical relationships by have one object contain another, is probably the most popular XML schema design pattern.  Here is an example from XAML:

 <Window ID="root">

  <Button>Hello World</Button>

 </Window>

Since <Button> element is inside <Window> element, the button is semantically within the window.  This is nice because syntatic structure matches semantic structure.  Here is an alternate solution that XML designs often overlook:

 <XAML>

  <Window ID="root">

   <Window.Background>Blue</Window.Background>

  </Window>

  <Button ID="mybtn">Hello World</Button>

  <Insert object="btn" into="root"/>

  <Center object="btn" to="root"/>

  <Move object="btn" x="10" y="20"/>

 </XAML>

In the first approach, object properties and contents are specified together.  In fact, there is no real distinction between object properties and contents.  If there is a need to distinguish the two, syntax has to be changed by introducing a separator or a container like <Content>.  Problem gets worse when new a new aspect needs to be added.

In the second approach, contents and operations are separated from objects.  Admittedly, this approach is less visually appealing.  However the syntax is simpler to process because the unit of processing is clearly defined: immediate children of the document element.

BTW, I am not advocating one design pattern over another.  I just thought it might be helpful for people to see alternative approaches to designing XML data.