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,</p>
<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")]
public class 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.