To talk a little about what Alex said:
XML does not have a period value in the element name. a , a. , ab and abc are all legal (and unique) element names.
In XAML, there is significant meaning for a period in an element name. Oddly enough, Alex's recommendation quotes, warning you to use period characters in your XML, which is why XAML uses periods: so that XamlReader can determine when it sees first.name that name is a property of the first object. Consequently:
<ListBox> <ListBox.BorderThickness>2</ListBox.BorderThickness> <ListBox.BorderBrush>Yellow</ListBox.BorderBrush> <TextBox>foo</TextBox> <TextBox>bar</TextBox> <TextBox>baz</TextBox> </ListBox>
Why can't you just do it?
<ListBox> <BorderThickness>2</BorderThickness> ...
There are two reasons. The first is a simple XML design: XML elements can contain multiple elements with the same name. Actually, it is a bad idea to model properties as children, because then you need to ensure uniqueness in your schema or have a rule for what to do with an object property when there are several children with the same name:
<ListBox> <BorderThickness>2</BorderThickness> <BorderThickness>3</BorderThickness> <BorderThickness>4</BorderThickness> ...
This is why XAML models properties as attributes that XML must be unique:
<ListBox BorderThickness='2' BorderBrush='Yellow'...
(By the way, the problem of using attributes in XAML is: if the properties on the object must be set in a specific order, you should not use the attributes to represent them. It happens that XamlReader reads the attributes in the order in which they appear in the element and assigns them properties in that order, but tools that read and write XML do not guarantee that attribute order is maintained, which means that the person who asked this troubling question can bring grief.)
Another reason is because so many WPF objects are containers of other objects. If XAML allowed elements to represent properties, you would be screwed up if you needed to represent an object that had a property with the same name as the class of the object that it could contain. For example, you could create an ItemsControl that had a Label property, but what happens if you want to save Label objects in the Items property? This ambiguity cannot occur in XAML:
<MyItemsControl> <MyItemsControl.Label>this is a property of MyItemsControl</MyItemsControl.Label> <Label>this is an item that MyItemsControl contains</Label> </MyItemsControl>