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

As far as I know, there's no specific significance for the '.' in XML. In other words, <a.b> is a different and unrelated tag from <a>. The relationship in XAML is a semantic understood by the XAML parser only.

On a separate note, the snippet in your question is not XAML; it's part of the deployment manifest for a Silverlight application. Again, though, the semantic of the '.' is understood by the manifest parser, not the XML parser.

Answer 2

XML's naming rules are clearly explained e.g. here:

XML elements must follow these naming rules:

• Names can contain letters, numbers, and other characters
• Names cannot start with a number or punctuation character
• Names cannot start with the letters xml (or XML, or Xml, etc)
• Names cannot contain spaces

Any name can be used, no words are reserved.

The URL I gave continues with "best practices" recommendations which do include

Avoid "." characters. If you name something "first.name," some software may think that "name" is a property of the object "first."

But, this is just a recommendation (breaking it may make your XML kind of hard to use with certain software), just like the one agains using -. Out of the recommendations, the only really crucial one is to avoid using : in XML names (since that does conflict with XML namespaces!-).

Answer 3

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>

Answer 4

Found this today in WPF in Action with Visual Studio 2008 by Feldman and Daymon

4.2.3. Using attached properties

You may have noticed an interesting thing about the property values in listing 4.2. Properties such as Width and Padding look like regular XML attributes. But the Left and Top properties' notation is a little different:

<Button Canvas.Left="40" Canvas.Top="40" >

Button does not have properties for Left and Top. Unlike Windows Forms, which assumed that everything has an explicit location, the working assumption for WPF is that the parent is responsible for the placement of each control. You'll see this with the other layout types. In the case of a Canvas, each control has to have its explicit location set. Because it is the Canvas layout that requires this information, it is up to the Canvas layout to handle this information.

In "classic" XML (that is, XML that could be validated by a Schema), you'd normally have to introduce an element around each child to specify the properties specific to the parent—something like listing 4.3.

Listing 4.3. A way to set properties for children (but not supported by WPF)

<Canvas>
    <CanvasItem Left = "40" Top="40">
        <Button>Button1</Button>
    </CanvasItem>
</Canvas>

This approach would work but is quite verbose, particularly when you have a lot of nested items. It also implies a hierarchy that doesn't really exist. Rather than requiring more verbose XML and making Canvas follow a structure that it probably doesn't need, XAML introduces a notation that allows properties that belong to the parent to be defined on the child, via the use of the dot notation:

<Canvas>
  <Button Canvas.Left="40" Canvas.Top="50">Button1</Button>
</Canvas>

This should be read as "When you add the Button to the Canvas, tell the Canvas that the Button should be positioned at Left 40 and Top 40." These properties are called attached properties because they're attached to the child to which they refer, even though they belong to the containing control (the Canvas in this case). You'll see this notation throughout XAML for all sorts of properties. You just need to remember that properties with dots in the middle are really setting values that are used by the containing control. The nice thing is that, when you're editing the properties of the control in the property editor, attached properties are displayed as part of the set of the control's properties