period in XML tags

Question

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

 
     OutOfBrowserSettings Sh         


        

Answer 1

The short answer is that this is purely a XAML construct and it has no relevance in XML.

For XML a name with dot like <ListBox.BorderThickness> is just a unique tag name by itself with the dot being part of the name just like you can have a gmail id with dot in it. It has no special importance or meaning.

Why XAML uses the dot? This is simply a XAML format that means we are setting the said property of the element object. This is essentially for the XAML engine to process this and and it also makes the XAML readable and easy to understand.

Additional Info: Nice to know.

XAML in essence contain pairs of properties and its values and since they represent rather complex objects (leads to deeper hierarchy), it helps in determining which element is the property and which one is the value.

Whenever XAML compiler or you see <X.Y>, it means the Y property of X is being set.

It's also worth noting that XAML doesn't allow you to just stick in any XML code for values, the values are always wrapped up in relevant XAML objects and that's how it knows how to process that value.

For example:

    <ComboBox>
        <ComboBoxItem>
            Item One
        </ComboBoxItem>
        <ComboBoxItem>
            Item Two
        </ComboBoxItem>
    </ComboBox>

It is easy to conceptually see that in above but of course the common and recommended syntax is following which is just short and easy to see:

    <ComboBox>
        <ComboBoxItem Content="Item One"/>
        <ComboBoxItem Content="Item Two"/>
    </ComboBox>

It may not make too much sense in the simple case but imagine your combobox item is a complex item (Say a C# class named House which was two properties Bedrooms and Baths). Then the ComboBoxItem will look like this:

        <ComboBoxItem>
            <local:House Bedrooms="3" Baths="2"/>
        </ComboBoxItem>

So now since its ComboBoxItem, you can selected it etc and do any operation that you would could on an item in combobox. Because you have <ComboBoxItem> tag, you can contain any complex structure inside that (for example using panels) and XAML engine will know all that is one item. It can probably figure that out without this tag too but imagine how difficult would it be for someone to read and understand that code.

This is also why when you are providing Style, you wrap your styles in top Style object as below:

    <Label Content="My Label">
        <Label.Height> 30</Label.Height>
        <Label.Style>
            <Style TargetType="Label">
                <Style.Triggers>
                    <Trigger Property="IsMouseOver" Value="True">
                        <Setter Property="Background" Value="Red"/>
                    </Trigger>
                </Style.Triggers>
            </Style>
        </Label.Style>
    </Label>

And this is also why there usually is a deeper hierarchy in XAML, one thing into another, that into another, that into another :)

Answer 2

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

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

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 5

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.