period in XML tags

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>

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.


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

Tags:

Xml

Xaml

Recent Posts