What is Namespace?
Before using or talking about namespaces let's talk about what is this? Namespaces are an abstract container or environment created to hold a logical grouping of unique identifiers or symbols. An identifier defined in a namespace is associated only with that namespace. The same identifier can be independently defined in multiple namespaces. That is, the meaning associated with an identifier defined in one namespace may or may not have the same meaning as the same identifier defined in another namespace. Languages that support namespaces specify the rules that determine to which namespace an identifier belongs.
<?xml version="1.0" encoding="UTF-8"?>
<users xmlns=" http://www.w3.org/1999/xhtml">
<name>ABHIMANYU KUMAR VATSA</name>
As in the above code, the xmlns name is a uniform resource identifier (URI). Typically, the URI chosen for the namespace of a given XML vocabulary describes a resource under the control of the author or organization defining the vocabulary, such as a URL for the author's Web server. However, the namespace specification does not require nor suggest that the namespace URI be used to retrieve information; it is simply treated by an XML parser as a string. For example, the document at http://www.w3.org/1999/xhtml itself does not contain any code. It simply describes the XHTML namespace to human readers. Using a URI (such as "http://www.w3.org/1999/xhtml" ) to identify a namespace, rather than a simple string (such as "xhtml"), reduces the possibility of different namespaces using duplicate identifiers. Although the term namespace URI is widespread, the W3C Recommendation refers to it as the namespace name. The specification is not entirely prescriptive about the precise rules for namespace names (it does not explicitly say that parsers must reject documents where the namespace name is not a valid Uniform Resource Identifier), and many XML parsers allow any character string to be used. In version 1.0 of the recommendation, the namespace name becomes an Internationalized Resource Identifier, which licenses the use of non-ASCII characters that in practice were already accepted by nearly all XML software. The term namespace URI persists, however, not only in popular usage but also in many other specifications from W3C and elsewhere.
Look at the sample code shown below of a XAML file; remember the code we have already used in the Hello Program.
<Grid x:Name="LayoutRoot" Background="White" ShowGridLines="True">
A XAML namespace is an extension of the concept of an XML namespace. The techniques of specifying a XAML namespace matches with XML namespace syntax (little), the convention of using URIs as namespace identifiers, using prefixes to provide a means to reference multiple namespaces from the same markup source, and so on. The primary concept that is added to the XAML definition of the XML namespace is that a XAML namespace implies both a scope of uniqueness for the markup usages, and also influences how markup entities are potentially backed by specific CLR namespaces and referenced assemblies. A XAML file must have only one root element, in order to be both a well-formed XML file and a valid XAML file. The root element also contains the attributes xmlns and xmlns:x. These attributes indicate to a XAML processor which XAML namespaces contain the type definitions for backing types that the markup will reference as elements. The xmlns attribute specifically indicates the default XAML namespace. Within the default XAML namespace, object elements in the markup can be specified without a prefix. The xmlns:x attribute indicates an additional XAML namespace, which maps the XAML language namespace http://schemas.microsoft.com/winfx/2006/xaml. This usage of xmlns to define a scope for usage and mapping of a name scope is consistent with the XML 1.0 specification. XAML name scopes are different from XML name scopes only in that a XAML name scope also implies something about how the name scope's elements are backed by types when it comes to type resolution and parsing the XAML. Please note that the xmlns attributes are only strictly necessary on the root element of each XAML file. xmlns definitions will apply to all descendant elements of the root element. Attributes are also permitted on other elements underneath the root, and would apply to any descendant elements of the defining element. However, frequent definition or redefinition of XAML namespaces can result in a XAML markup style that is difficult to read.
In the previous example, the prefix x: was used to map the XAML namespacehttp://schemas.microsoft.com/winfx/2006/xaml, which is the dedicated XAML namespace that supports XAML language constructs. This x: prefix is used for mapping this XAML namespace in the templates for projects, in examples, and in documentation throughout this SDK. The XAML namespace for the XAML language contain several programming constructs that you will use very frequently in your XAML. The following examples are most common x: prefix programming constructs we use:
This attribute specifies a run-time object name for the instance that exists in run-time code after an object element is processed.
This attribute specifies the namespace and class name for the class that provides code-behind for a XAML page. We must have a class to support code-behind.
If you are aware of WPF namespaces, you will notice that default namespaces are not the same because Silverlight XAML is a subset of WPF XAML.
Using own Namespaces
In many situations we need to use custom Silverlight controls that may be developed by you or another developer. In this case you will have to access to your own namespace to use that control. For this you have to define a new namespace prefix and map it to your assembly. Look at the syntax you need:
<TextBox a:Name="txtInput" Margin="5"/>
In above example, 'a' is the namespace prefix I will be using, you can choose anything you want but remember it doesn't conflict with another used namespace prefix. The 'clr' namespace declared within assembly that contains the public type to expose as element and class is located in 'Widgets' namespace, classes are part of 'Widgets.dll' assembly. We always precede this assembly with ClientBin.