Peter McGrattan’s Weblog

Silverlight, WCF, ASP.NET, AJAX, Graphics, RIA

Beta 2 Xaml Namespaces

Posted by petermcg on June 16, 2008

The default XML namespace used by XAML in Silverlight 2 has changed in the transition from Beta 1 to Beta 2.  The two namespaces defined by default in Beta 1 were as follows :

<UserControl xmlns=""

In Beta 2 the default namespace has changed :

<UserControl xmlns=""

The change has more than likely occurred as part of the work to make the Silverlight 2 API more compatible with WPF, although WPF 3.5 does define a new XML namespace :


Compatibility should still be maintained however as this namespace or the namespace defined in WPF 3.0 can be used when building WPF 3.5 applications.

XML Namespaces

An XML namespace must be a valid Uniform Resource Identifier (URI), a URI can either be a Uniform Resource Locator (URL) as in the above examples or a Uniform Resource Name (URN) as in the example below :


These URI’s do not resolve to any useful resource if you put them in the address bar in Internet Explorer for example, their only job is to be unique.  A common way to guarantee that uniqueness throughout the XAML’s travels is to start by using a domain name previously registered with an Internet Naming Authority such as and add a custom suffix such as netfx/2007/xaml/presentation.

The Default Namespace

There can be only one default XML namespace for an element, any additional namespaces must use a prefix.  In the default XAML markup below, the URI specified by the xmlns identifier without any prefix is the default namespace for the UserControl element and it’s descendant elements (the namespace’s scope) but default namespaces have no affect on attributes.  This means that all unqualified element names within the default namespace’s scope (UserControl and Grid) are implicitly associated with that namespace’s URI.

<UserControl x:Class="SilverlightApplication1.Page"
    Width="400" Height="300">
    <Grid x:Name="LayoutRoot" Background="White">


This is important because it is this implicit namespace URI that the XAML processor uses to search referenced assemblies to find the matching CLR Type for these unqualified elements.  The image below shows the default references for a standard Silverlight Application containing the above markup :

Default References

These referenced assemblies are searched by the XAML processor for a predefined, hardcoded attribute (the XmlnsDefinition attribute) defining this implicit URI as it’s ‘key’ :

System.Windows Assembly Attributes

When found, as many are in the System.Windows.dll assembly only, the name of a CLR namespace is retrieved from the ‘value’ of the same attribute.  This CLR namespace is then returned as a scope for the XAML processor to search within to find the matching CLR Type for the XAML element.  Both the UserControl and the Grid types are found in the System.Windows.Controls CLR namespace in this way :

UserControl Grid

You can see from the illustration above that twelve CLR namespaces in the System.Windows.dll assembly are mapped to the Silverlight Beta 2 default XAML namespace and that the Beta 1 namespace is currently still supported.  Note that this process is also the method by which the CLR Application type, instantiated by the the Silverlight plug-in control, is mapped :

<Application xmlns=""


Using the default XML namespace on the Application element in App.xaml, this fundamental CLR type is found in the System.Windows namespace again in the System.Windows.dll assembly :


Prefixed Namespaces

To recap, there can be only one default XML namespace for an element, any additional namespaces must use a prefix and default namespaces have no affect on attributes.  In order to affect an attribute with a namespace a prefix must be used, the prefix then becomes an abbreviation for that namespace.  In this way the x prefix is used by convention with it’s corresponding pre-defined URI to fulfil Silverlight’s contract as an implementation of the XAML language :


The XAML language expects implementers of it’s syntax to expose certain fundamental attributes such as x:Class and x:Name (as show in the examples above) so the processor can perform duties such as joining a code-behind file to a XAML file through a partial class and creating members of that class with meaningful names.  This functionality is manifest in the System.Windows.Markup namespace also in the System.Windows.dll assembly.

For more information on XML namespaces in general and how they affect the family of XML technologies, have a look here and here.


Sorry, the comment form is closed at this time.

%d bloggers like this: