period in XML tags

Question

Studying XAML now, I keep seeing XAML tags in the format Object.Attribute. For example:

 <Deployment.OutOfBrowserSettings>
     OutOfBrowserSettings ShortName="Hello World" >

Don't recall seeing XML attributes like this before, always would see simple words, or possible a namespace column prefix such as x:application. So, to express an object/attribute relation as in above I would expect a notation such as:

<Deployment>
   <OutOfBrowserSettings ShortName="Hello World" >

So, my question is this: What's the significance of the '.' notation inside XML tags. What are the semantics? Is it specific to XAML?

Answer 1

To expand a little on what Alex said:

To XML, there's no significance of a period in an element's name. a, a., a.b, and a.b.c are all legal (and unique) element names.

To XAML, there's considerable significance to a period in an element's name. Ironically, the recommendation Alex quotes, warning you away from using period characters in your XML, is exactly why XAML uses periods: so that the XamlReader can tell, when it sees first.name, that name is a property of the object first. Hence:

<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 this?

<ListBox>
   <BorderThickness>2</BorderThickness>
   ...

There are two reasons. The first is simple XML design: XML elements can contain multiple elements with the same name. It's actually a bad idea to model properties as child elements, because then you have to enforce uniqueness in your schema, or have a rule for what to do with the object's property when there are multiple child elements with the same name:

<ListBox>
   <BorderThickness>2</BorderThickness>
   <BorderThickness>3</BorderThickness>
   <BorderThickness>4</BorderThickness>
   ...

That's why XAML models properties as attributes, which XML requires be unique:

<ListBox BorderThickness='2' BorderBrush='Yellow'...

(BTW, there's a problem with the use of attributes in XAML: If the properties on an object must be set in a specific order, you shouldn't use attributes to represent them. It happens that the XamlReader reads the attributes in the order that they appear in the element, and assigns them to the properties in that order. But tools that read and write XML aren't guaranteed to preserve the order of attributes. Which means that the person who asked this disturbing question may come to grief.)

The other reason is that so many WPF objects are containers of other objects. If XAML allowed elements to represent properties, you'd be screwed if you needed to represent an object that had a property with the same name as the class of an object it could contain. For instance, you could certainly create an ItemsControl that had a Label property, but what would happen if you wanted to store Label objects in its Items property? This ambiguity can't arise in XAML:

<MyItemsControl>
   <MyItemsControl.Label>this is a property of MyItemsControl</MyItemsControl.Label>
   <Label>this is an item that MyItemsControl contains</Label>
</MyItemsControl>