Powershell – Using PowerShell, how to add multiple namespaces (one of which is the default namespace)

There is actually a (subtle) difference between the two. Imagine you have the following code in File1.cs:

// File1.cs
using System;
namespace Outer.Inner
{
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

Now imagine that someone adds another file (File2.cs) to the project that looks like this:

// File2.cs
namespace Outer
{
    class Math
    {
    }
}

The compiler searches Outer before looking at those using directives outside the namespace, so it finds Outer.Math instead of System.Math. Unfortunately (or perhaps fortunately?), Outer.Math has no PI member, so File1 is now broken.

This changes if you put the using inside your namespace declaration, as follows:

// File1b.cs
namespace Outer.Inner
{
    using System;
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

Now the compiler searches System before searching Outer, finds System.Math, and all is well.

Some would argue that Math might be a bad name for a user-defined class, since there's already one in System; the point here is just that there is a difference, and it affects the maintainability of your code.

It's also interesting to note what happens if Foo is in namespace Outer, rather than Outer.Inner. In that case, adding Outer.Math in File2 breaks File1 regardless of where the using goes. This implies that the compiler searches the innermost enclosing namespace before it looks at any using directive.

There's quite a lot of confusion evident in your question, and it's not easy to resolve it without writing an entire tutorial on XML namespaces. I'll try cover as best I can how they relate to (X)HTML.

First though, the purpose of namespaces is to separate vocabularies. So, for example, the title element in the http://www.w3.org/1999/xhtml namespace can be distinguished from the title element in the http://www.w3.org/2000/svg namespace, when they appear in the same document, or processed by a common processor.

Second, forget about the http://www.w3.org/2000/xmlns/ namespace. What it does is largely behind the scenes and you rarely need to worry about it.

Next, we need to distinguish between the null namespace, the default namespace, and namespaces referenced by prefixes.

When an XML file has no xmlns= attributes defined, all the unprefixed elements are said to be 'in the null namespace', or 'in no namespace' which amounts to the same thing.

When an XML element has an xmlns= attribute, it and its descendant elements, if they are unprefixed are said to be 'in the default namespace' where the default namespace is the value of the xmlns attribute.

Prefixed elements are always in the namespace mapped by xmlns:prefix= attributes in the element or ancestor of the element.

Now, the XHTML vocabulary is defined as elements in the http://www.w3.org/1999/xhtml namespace, so a correctly written XHTML document will declare either that namespace as being the default namespace, or will map a prefix to the namespace, in which case all the XHTML elements will need to include that prefix on their names. (This latter situation doesn't happen very often, for reasons given below).

So, when parsing XHTML with an XML parser, the namespace mapping needs to be there.

However, XPath has no concept of a default namespace. If you don't put the prefix on the elements named in the xpath, it will attempt to match elements in the null namespace. If the XHTML elements are in the http://www.w3.org/1999/xhtml namespace, then the xpath won't match anything.

This is where it starts to get complicated - browsers.

If you serve XHTML web pages to browsers as you should, with an XML content type like application/xhtml+xml, the browser will use an XML parser to load it and all the above rules apply. If you don't include the xmlns="http://www.w3.org/1999/xhtml" attribute, browsers won't understand how to process it and will simply display the file as a raw XML structure.

However, because IE until IE9 didn't support XML content-types, hardly anybody does serve their web pages that way. Instead they use the "text/html" content type, in which case the browser doesn't use an XML parser at all, it uses an HTML one.

The HTML parser just ignores the namespace to prefix mappings, and simply "knows" which element names belong in which namespaces. This makes it ultimately less flexible, but within its specialized domain, more robust and simple to use. (In the example of the title element above, it determines which namespace applies by looking at the titles ancestor elements) This is why XHTML documents don't use prefixed elements, because an HTML parser won't recognise them.

Browsers, (the modern ones anyway), then have specialized DOM-alike API methods and CSS rules to hide all this namespace complexity away from the javascript and css author, and thus, for the most part, namespacing can be safely ignored by web authors.

Standalone HTML parsers, however, don't always do this. Instead, they place all the elements in the null namespace, which means that they can be found with xpaths that don't include prefixes on the element names, using standard DOM APIs. For most practical purposes, this amounts to the same thing as when browser parse using their HTML parser.

So, in summary, you need to be aware of whether you are parsing your XHTML with an XML or HTML parser, and how that particular parser is assigning elements to namespaces, in order to be able to write a correct xpath to query for elements within the document.