Need of namespace in XML

Question

I understand that within a XML if I have same tagName for two different tags, then to separate the two of them, we precede it with the namespace to make it unique. but in the top when we say

<rootElement xmlns:myNameSpace="http://www.myNameSpace.com">

Now, why do we have this http://www.myNameSpace.com? What purpose does this serve, apart from the fact that it will be unique.

Also, I was reading about xslt, and since it is also a XML then it defined the namespace as

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

Now, first, what exactly does this link tell me and how does it help in xml rendering? So does it serve anything other than the uniqueness? And why go to such extent? If at all within a XML, I have conflict between two tags, I can just use any two namespaces, say namespace1 and namespace2 and work with it.

Is there something I am missing here?

Answer 1

In general, an XML namespace does not serve any purpose apart from uniquely identifying the elements that are associated with it.

In other words, the String "http://www.myNameSpace.com" as in:

<rootElement xmlns:myNameSpace="http://www.myNameSpace.com">

is purely arbitrary. It does not have to point anywhere. Also, the so-called prefix (in this case myNameSpace, the part right after "xmlns:") is arbitrary and just a shorthand way of saying "http://www.myNameSpace.com".

Having said that, a few reservations:

1) Namespaces can help structure your XML data in large files, for example a Microsoft Word document in OpenXML format:

This is an excerpt of the namespaces present in typical OOXML:

xmlns:aml="http://schemas.microsoft.com/aml/2001/core"
xmlns:wpc="http://schemas.microsoft.com/office/word/2010/wordprocessingCanvas"
xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

So, although there is no inherent reason to have separate namespaces, it helps dividing your XML vocabulary into meaningful categories.

2) There are a few constraints on arbitrarily defining namespaces, as you noticed:

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

This identifies elements as belonging to the XSLT namespace. But also, beyond that, it means that elements thus marked are identified by an XSLT processor as not merely being XML code, but an XSLT instruction to be carried out.

The link "http://www.w3.org/1999/XSL/Transform" points to the XSLT specification, where the rules for transforming XML documents are laid down. Now, to answer your question: Declaring the namespace does not help the transformation. Rather, an XSLT processor does not recognize XSLT code if you omit it.

You can define the namespaces "namespaceA" and "namespaceB":

xmlns:nsA="namespaceA"
xmlns:nsB="namespaceB"

but you cannot use them to transform XML, unless you meant to just change the prefix:

xmlns:nsA="http://www.w3.org/1999/XSL/Transform"

which is considered bad practice.

Answer 2

You've pretty much nailed it, i.e. the xmlns is unique. In addition, it must be a valid URI as per the W3C spec.

From Wikipedia:

A namespace 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.

Re : XSLT

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

This means the namespace prefix xsl is now 'aliased' to the xmlns "http://www.w3.org/1999/XSL/Transform" - i.e. all further identifiers in the document which reference the xsl prefix belong in this namespace.

Re : Comment

The choice of xsl as the prefix is by convention for xslt stylesheets. There is nothing stopping you from using another alias, e.g.:

<?xml version="1.0" encoding="utf-8"?>
<bob:stylesheet version="1.0" xmlns:bob="http://www.w3.org/1999/XSL/Transform">
   <bob:template match="/xml">
      <bob:value-of select="element"/>
   </bob:template>
</bob:stylesheet>

But this isn't going to win you any friends.

You can also choose not to use the prefix, but then you'll need to repeat the xmlns everywhere e.g.

<value-of select="element" xmlns="http://www.w3.org/1999/XSL/Transform"/>

Answer 3

The essence of XML Namespaces is that from the abstract data model point of view the name of an element/attribute/type/etc. consists of two parts, the namespace name (often called the "namespace URI") and the local part.

An element with namespace http://www.w3.org/1999/XSL/Transform and local part stylesheet is different from an element with namespace http://example.com and local part stylesheet, which in turn is different from an element with the local name stylesheet but no namespace. An XSLT processor would treat the first of those as an instruction but the second and third simply as literal elements to be output.

It would be very verbose if you had to type out namespace names in full for every element:

<{http://www.w3.org/1999/XSL/Transform}stylesheet version="1.0">
  <{http://www.w3.org/1999/XSL/Transform}template match="/">
    <!-- ... -->
  </{http://www.w3.org/1999/XSL/Transform}template>
</{http://www.w3.org/1999/XSL/Transform}stylesheet>

so instead you use xmlns and xmlns:prefix declarations to associate short (or empty) labels with the full namespace names, and then use those prefixes along with local names to provide the full name for each element. The prefix is not part of the name as far as a namespace-aware XML processor is concerned - it makes no difference what prefix you choose to use as long as it is bound to the correct namespace.

However there are conventional prefixes that most people tend to use for common namespaces, for example xsl for XSLT, xs or xsd for XML schema, xsi for http://www.w3.org/2001/XMLSchema-instance, etc. and if you are writing XML that uses one of these vocabularies then it's a good idea to stick to the conventions if other people may need to read your documents in future.