If you misspell an attribute name in an HTML document the browser will simply ignore it. For example, if you spell the href attribute as zhref the <a> tag the attribute will be ignored. For example, this is text is in such an <a> tag. It is displayed like a link but it doesn't go anywhere because it doesn't contain an href attribute. Intentional misspellings can be used to temporarily comment out an attributes or an element. XAML doesn't support this technique directly. If you misspell an attribute or an element the XAML parser will emit an error message and refused to produce a BAML file or load the document dynamically. This is the behavior you want if you unintentionally misspelled an attribute. The compiler will tell you exactly where the error is and you can quickly find and fix the problem. But temporarily commenting out an attribute can sometimes be useful when experimenting or prototyping. XAML provides a way to duplicate the this commenting out technique through the use of the markup compatibility namespace. Markup compatibility tells the parser which namespaces are not required to be recognized when loading a XAML document. If you declare a namespace that will never be recognized, such as "Comment", you can use that namespace to comment out items by using its prefix. For example, let say you want to see the effect of removing the Width property of a Button but not lose the value it currently has which would happen if you simply deleted it. Consider the following,

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"> 
  <Canvas>
    <Button Canvas.Top="50" Canvas.Left="50" Width="100" Height="50">
      Hello
    </Button>
  </Canvas>
</Window>

To comment out the Width attribute you can add the markup compatibility namespace, then an unknown namespace, and finally declare the unknown namespace ignorable. This might look like,

<Window
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:c="Comment"
    mc:Ignorable="c">
  <Canvas>
    <Button Canvas.Top="50" Canvas.Left="50" Width="100" Height="50">
      Hello
    </Button>
  </Canvas>
</Window>

You can then comment out the Width and Height attributes,

<Window
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:c="Comment"
    mc:Ignorable="c">
  <Canvas>
    <Button Canvas.Top="50" Canvas.Left="50" c:Width="100" c:Height="50">
      Hello
    </Button>
  </Canvas>
</Window>

You can even comment out the entire Button with,

<Window
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:c="Comment"
    mc:Ignorable="c">
  <Canvas>
    <c:Button Canvas.Top="50" Canvas.Left="50" Width="100" Height="50">
      Hello
    </c:Button>
  </Canvas>
</Window>

I only recommend this when you are prototyping. You shouldn't have commented out text in production XAML files. Fortunately, this technique makes it easy to determine if you have removed all such commented out items. Simply delete the xmlns:c and mc:Ignorable declarations from Window. The compiler will now generate and error if you haven't removed comment prefixes. Finally, this technique makes it clear to any reader (both mechanical and human) that you intended to comment out this property, you simple didn't just misspell it.

Returning to the Party example we where using, lets say you want to author a document that has 10 kazoos when the version 2 assembly is present but replaces them with 4 extra balloons if we only have the version 1 assembly. This can be written using a markup compatibility AlternateContent block. This might look like,

    <Party mc:Ignorable="v2"
      xmln="...assembly-v1-uri..."
      xmlns:v2="...assembly-v2-uri..."
      xmlns:mc="http://schemas.micrsoft.com/winfx/2006/markup-compatibility">
        <Balloon Color="Red" />
        <Balloon Color="Blue" />
        <mc:AlternateContent>
            <mc:Choice Requires="v2">
                <Balloon Color="Green" Shape="Dog" />
                <v2:Favor Kind="Kazoo" Quantity="10" />
            </mc:Choice>
            <mc:Fallback>
                <Balloon Color="Green" />
                <Balloon Color="Violet" />
                <Balloon Color="Orange" />
                <Balloon Color="Yellow" />
            </mc:Fallback>
        </mc:AlternateContent>
    </Party>

When the version 1 assembly is present this is interpreted as,

    <Party xmln="...assembly-v1-uri...">
        <Balloon Color="Red" />
        <Balloon Color="Blue" />
        <Balloon Color="Green" />
        <Balloon Color="Violet" />
        <Balloon Color="Orange" />
        <Balloon Color="Yellow" />
    </Party>

but in version 2 it is interpreted as,

    <Party xmlns="...assembly-v2-uri...">
        <Balloon Color="Red" />
        <Balloon Color="Blue" />
        <Balloon Color="Green" Shape="Dog" />
        <Favor Kind="Kazoo" Quantity="10" />
    </Party>

The content of the Choice element is used when the v2 namespace is available because it is mentioned in the Requires attribute. This corresponds to when the version 2 assembly is in use. If v2 is not available, the content of the Fallback element is used. AlternateContent supports an arbitrary list of Choice elements and the Requires can be an arbitrary list of prefix names.

Of course exchanging balloons for kazoos is not a very compelling example. For a more practical example, let's assume we have following classes in version 1 of an assembly,

    [ContentProperty("Content")]
    class Paragraph {
        private List<Inline> _content = new List<Inline>();
        public List<Inline> Content { get { return _content; } }
    }
    
    abstractclass Inline { }
    
    [ContentProperty("Text")]
    class Run : Inline {
        string _text;
        publicstring Text { get { return _text; } set { _text = value; } }
    }
    
    class Image : Inline {
        private Uri _source;
        public Uri Source { get { return _source; } set { _source = value; } }
    }

Now in the version 2 assembly we add a new class that looks like,

          class Graph : Inline {
        private List<Point> _points = new List<Point>();
        public List<Point> Points { get { return _points; } }
    }

Now we want to write a paragraph that uses the new Graph class when version 2 of the assembly is present, because, for example, it scales better, but in version 1 we will just use a bitmap image of the graph. This might look like,

    <Paragraph mc:Ignorable="v2"
      xmln="...assembly-v1-uri..."
      xmlns:v2="...assembly-v2-uri..."
      xmlns:mc="http://schemas.micrsoft.com/winfx/2006/markup-compatibility">
        <Run>The sales projects for the next quarter are</Run>
        <AlternateContent>
            <mc:Choice Requires="v2">
                <v2:Graph Data="1,2 2,3 3,5" />
            </mc:Choice>
            <mc:Fallback>
                 <Image Source="SalesData.jpg" />
            </mc:Fallback>
        </mc:AlternateContent>
    </Paragraph>

When the version 2 assembly is present, this is interpreted as,

    <Paragraph xmlns="...assembly-v2-uri...">
        <Run>The sales projects for the next quarter are</Run>
        <Graph Data="1,2 2,3 3,5" />
    </Paragraph>

but, when only version 1 available, it is interpreted as,

    <Paragraph xmln="...assembly-v1-uri...">
        <Run>The sales projects for the next quarter are</Run>
        <Image Source="SalesData.jpg" />
    </Paragraph>

using the bitmap instead of of the Graph class. This allows a document author to produce a file that takes advantage of a new feature, such as Graph with its better scaling properties, but still allows older versions to see a the graph at a lower fidelity.

These classes make a better example for another feature of markup compatibility, the ProcessContent attribute. Let's add another class in the version 2 assembly,

    [ContentProperty("Content")]
    class Glow : Inline {
        private List<Inline> _content = new List<Inline>();
        public List<Inline> Content { get { return _content; } }
    }

This class allows us to make the content to appear to glow when drawn. This allows us to write a document that looks like,

    <Paragraph mc:Ignorable="v2"
      xmln="...assembly-v1-uri..."
      xmlns:v2="...assembly-v2-uri..."
      xmlns:mc="http://schemas.micrsoft.com/winfx/2006/markup-compatibility">
        <Run>The word</Run> 
        <v2:Glow><Run>glow</Run></v2:Glow> 
        <Run>will appear to glow when it viewed with version 2.</Run>
    </Paragraph>

Unfortunately, with version 1, this is interpreted as,

    <Paragraph xmln="...assembly-v1-uri...">
        <Run>The word</Run> 
        <Run>will appear to glow when it viewed with version 2.</Run>
    </Paragraph>

The word "glow" disappeared because, by default, when an element is ignored its content is ignored as well. This default can be modified by using the ProcessContent attribute. If the original document is modified to be,

    <Paragraph 
      mc:Ignorable="v2" 
      mc:ProcessContent="v2:Glow"
      xmln="...assembly-v1-uri..."
      xmlns:v2="...assembly-v2-uri..."
      xmlns:mc="http://schemas.micrsoft.com/winfx/2006/markup-compatibility">
        <Run>The word</Run> 
        <v2:Glow><Run>glow</Run></v2:Glow> 
        <Run>will appear to glow when it viewed with version 2.</Run>
    </Paragraph>

This will tell the reader to just ignore the tags for Glow if it doesn't understand it but leave the content intact. This is then interpreted as,

    <Paragraph xmln="...assembly-v1-uri...">
        <Run>The word</Run> 
        <Run>glow</Run>
        <Run>will appear to glow when it viewed with version 2.</Run>
    </Paragraph>

for version 1, and will be interpreted as,

    <Paragraph xmlns:v2="...assembly-v2-uri...">
        <Run>The word</Run> 
        <Glow><Run>glow</Run></Glow> 
        <Run>will appear to glow when it viewed with version 2.</Run>
    </Paragraph>

when version 2 is present which is exactly what we wanted.

In general, forward compatibility allows previous versions of a document reader to read a document intended for later versions and render the content at a lower fidelity. This helps immensely when deploying a newer version of an assembly. During initial deployment it might not be that wide spread. You can have your users start taking advantage of the new features immediately because older versions will still be able to read newer documents, at a lower fidelity, even when they don't have the new assembly.

As we saw last time, XAML supports backwards compatibility. XAML also supports forward compatibility. Forward compatibility is easiest to understand from through a set of examples. Take the balloon example before. Say we want to write a XAML document that says, when you have the version 2 assembly, I want a dog shaped balloon. If, however, you only have the version 1 assembly, a default shaped balloon is fine. In other words, I want a document that contains some version 2 specific references in it but it is OK to just ignore them when you have a version 1 assembly. In our example, we want to mark the Shape property some way that the version 1 reader will know it can ignore the property. In XAML you can use the markup compatibility namespace to accomplish this. You can write,

    <Balloon Color="Red" v2:Shape="Dog" 
      xmlns="...assembly-v1-uri..."
      xmlns:v2="...assembly-v2-uri..."
      xmlns:mc="http://schemas.micrsoft.com/winfx/2006/markup-compatibility"
      mc:Ignorable="v2" />

This takes advantage of the Ignorable attribute of from the markup compatibility namespace. mc:Ignorable="v2" says that any attribute or element from the namespace associated with the "v2" prefix can be ignored and you would still have a document that would have an acceptable meaning. If a XAML reader only has the version 1 assembly, it would interpreted the above document as,

    <Balloon Color="Red" xmlns="...assembly-v1-uri..."  />

If the reader has the version 2 assembly, it would interpret it as,

    <Balloon Color="Red" Shape="Dog" xmlns="...assembly-v2-uri..." />

mc:Ignorable can also applies to elements. To see example of this lets define a class, Party, that is define as,

    [ContentProperty("Balloons")]
    publicclass Party {
        List<Balloon> _balloons = new List<Balloon>();
        public List<Balloon> Balloons { get { return _balloons; } 
    }

This allows us to define a Party instance that contains balloons. For this example, let's assume that Party was defined in the Version 1 assembly and is unmodified in the Version 2 assembly. We can then write a XAML document that looks like,

    <Party xmln="...assembly-v1-uri...">
        <Balloon Color="Red" />
        <Balloon Color="Blue" />
    </Party>

We can now also write a document that will include a third dog shaped balloon but only if we are using the version 2 assembly, and not include if we are still using version 1. It looks like,

    <Party mc:Ignorable="v2"
      xmln="...assembly-v1-uri..."
      xmlns:v2="...assembly-v2-uri..."
      xmlns:mc="http://schemas.micrsoft.com/winfx/2006/markup-compatibility">
        <Balloon Color="Red" />
        <Balloon Color="Blue" />
        <v2:Balloon Color="Green" Shape="Dog" />
    </Party>

This will be interpreted exactly as the prior document when reading it with version 1. With version 2, however, it would be interpreted as if it was,

    <Party xmlns="...assembly-v2-uri...">
        <Balloon Color="Red" />
        <Balloon Color="Blue" />
        <Balloon Color="Green" Shape="Dog" />
    </Party>

We can also add a new a new class, such as Favor, that can be used in a document such as,

    <Party mc:Ignorable="v2"
      xmln="...assembly-v1-uri..."
      xmlns:v2="...assembly-v2-uri..."
      xmlns:mc="http://schemas.micrsoft.com/winfx/2006/markup-compatibility">
        <Balloon Color="Red" />
        <Balloon Color="Blue" />
        <v2:Balloon Color="Green" Shape="Dog" />
        <v2:Favor Kind="Kazoo" Quantity="10" />
    </Party>

This doesn't affect the version 1 interpretation of the document, but adds 10 kazoos to the version 2 interpretation. If the author determines that the kazoos are really necessary to the interpretation of either the reference to v1 can be removed and the document rewritten to,

    <Party xmlns="...assembly-v2-uri...">
        <Balloon Color="Red" />
        <Balloon Color="Blue" />
        <Balloon Color="Green" Shape="Dog" />
        <Favor Kind="Kazoo" Quantity="10" />
    </Party>

or the the ignorable attribute can just be removed which amounts to an equivalent document given subsumption described in the previous entry.

XAML provides two ways to set a property, either through a Property Attribute or through a Property Element. We covered Property Attributes last time, this time we will focus on the Property Element.

A Property Element is an element that, instead of creating an object instance, set the value of a property. The following is equivalent to the example given in Part I but uses Property Elements instead of Property Attributes.

  <Button xmlns="http://schemas.microsoft.com/winfx/avalon/2005">
    <Button.Content>
      Hello, World!
    </Button.Content>
  </Button>

The loader distinguishes a Object Element from a Property Element by the presents of the '.' in the name. The first part of the name is a reference to a type and the second part, after the dot, refers to the property name (we will discuss exactly why this is when we discuss Attached Properties). Here we use Button in both Property Elements. Property Elements are necessary when the value of the property cannot be expressed as a string. For example, you can use a Property Element to set the content of a Button to be another Button (not sure why you would want that, but suspend disbelieve for a second) as in,

  <Button xmlns="http://schemas.microsoft.com/winfx/avalon/2005">
    <Button.Content>
      <Button Content="Hello, World!" />
    </Button.Content>
  </Button>

This can be written more explicitly as,

  <Button xmlns="http://schemas.microsoft.com/winfx/avalon/2005">
    <Button.Content>
      <Button>
        <Button.Content>
          Hello, World!
        </Button.Content>
      </Button>
    </Button.Content>
  </Button>

As you can see, using Property Elements can become a bit repetitive. To mitigate this, one of the properties of a class can be designated as the Content Property which tells the load to assign direct content of the element to that property. In the case of Button (and all ContentControls) the Content Property is, oddly enough, set to the property named Content. This allows us to write something like,

  <Button xmlns="http://schemas.microsoft.com/winfx/avalon/2005">
    Hello, World!
  </Button>

for the first example above, and,

  <Button xmlns="http://schemas.microsoft.com/winfx/avalon/2005">
    <Button>Hello, World!</Button>
  </Button>

for the second. Most Avalon classes have a Content Property defined. For Panel's, such as DockPanel, Grid, and Canvas, their Content Property is set to their Children collection. Any direct content of a Panel is assumed to be content intended for the Children property. This means the following,

  <StackPanel xmlns="http://schemas.microsoft.com/winfx/avalon/2005">
    <Button>OK</Button>
    <Button>Cancel</Button>
  </StackPanel>

is an abbreviated version of,

  <StackPanel xmlns="http://schemas.microsoft.com/winfx/avalon/2005">
    <StackPanel.Children>
      <Button>
        <Button.Content>
          OK
        </Button.Content>
      </Button>
      <Button>
        <Button.Content>
          Cancel
        </Button.Content>
      </Button>
    </StackPanel.Children>
  </StackPanel>

Now, with Property Elements and Content Property Attributes and Object Element and Property Attribute from Part I, we have covered the fundamentals of XAML.

Cider is now announced! In case you missed it at the PDC, Cider is the code name for the Visual Studio Designer for WPF (pronounced Avalon according to Chris) that will be delivered in Orcas. We also announced the Expression product line that includes a different designer called Sparkle. Other than the obvious difference between Sparkle and Cider, Cider is in VS, Sparkle is a stand-alone product, Cider will be a designer for developers, Sparkle will be a designer targeted at professional designers.

For those that were asking about what I was working on, I wasn't trying to be coy, I just didn't want to spill the beans early.

I will be more forthcoming in the months ahead and try to keep you up-to-date with our progress.

If I missed you at the PDC, I am sorry about that. Feel free to ask your questions here or via e-mail (chuckj directed through microsoft.com).