It means XML namespace.
Basically, every element (or attribute) in XML belongs to a namespace, a way of "qualifying" the name of the element.
Imagine you and I both invent our own XML. You invent XML to describe people, I invent mine to describe cities. Both of us include an element called name
. Yours refers to the person’s name, and mine to the city name—OK, it’s a little bit contrived.
<person>
<name>Rob</name>
<age>37</age>
<homecity>
<name>London</name>
<lat>123.000</lat>
<long>0.00</long>
</homecity>
</person>
If our two XMLs were combined into a single document, how would we tell the two names apart? As you can see above, there are two name
elements, but they both have different meanings.
The answer is that you and I would both assign a namespace to our XML, which we would make unique:
<personxml:person xmlns:personxml="http://www.your.example.com/xml/person"
xmlns:cityxml="http://www.my.example.com/xml/cities">
<personxml:name>Rob</personxml:name>
<personxml:age>37</personxml:age>
<cityxml:homecity>
<cityxml:name>London</cityxml:name>
<cityxml:lat>123.000</cityxml:lat>
<cityxml:long>0.00</cityxml:long>
</cityxml:homecity>
</personxml:person>
Now we’ve fully qualified our XML, there is no ambiguity as to what each name
element means. All of the tags that start with personxml:
are tags belonging to your XML, all the ones that start with cityxml:
are mine.
There are a few points to note:
If you exclude any namespace declarations, things are considered to be in the default namespace.
If you declare a namespace without the identifier, that is, xmlns="http://somenamespace"
, rather than xmlns:rob="somenamespace"
, it specifies the default namespace for the document.
The actual namespace itself, often a IRI, is of no real consequence. It should be unique, so people tend to choose a IRI/URI that they own, but it has no greater meaning than that. Sometimes people will place the schema (definition) for the XML at the specified IRI, but that is a convention of some people only.
The prefix is of no consequence either. The only thing that matters is what namespace the prefix is defined as. Several tags beginning with different prefixes, all of which map to the same namespace are considered to be the same.
For instance, if the prefixes personxml
and mycityxml
both mapped to the same namespace (as in the snippet below), then it wouldn't matter if you prefixed a given element with personxml
or mycityxml
, they'd both be treated as the same thing by an XML parser. The point is that an XML parser doesn't care what you've chosen as the prefix, only the namespace it maps too. The prefix is just an indirection pointing to the namespace.
<personxml:person
xmlns:personxml="http://example.com/same/url"
xmlns:mycityxml="http://example.com/same/url" />
Attributes can be qualified but are generally not. They also do not inherit their namespace from the element they are on, as opposed to elements (see below).
Also, element namespaces are inherited from the parent element. In other words I could equally have written the above XML as
<person xmlns="http://www.your.example.com/xml/person">
<name>Rob</name>
<age>37</age>
<homecity xmlns="http://www.my.example.com/xml/cities">
<name>London</name>
<lat>123.000</lat>
<long>0.00</long>
</homecity>
</person>
To understand the difference between targetNamespace
and xmlns
, just think the following.
XSD is a language to describe XML schemas.
Any computer language must be expressed somehow, that is, have some operators, keywords ets. All those things are called grammar.
The authors of XSD (that is W3C) have decided not to invent yet another grammar,
but to use XML itself for that. So, XSD is expressed in XML. XML is the carrier for it.
Essentially, it is a sort of coincidence. It was chosen by the XSD authors for convenience
(and that convenience does exist indeed!).
But, that is not a necessary requirement. For instance, there is another XML schema language called RELAX NG, which is not based on XML.
But once XML is the carrier of all XSD texts, you have to deal with the XML-specific things and xmlns
is the one. Basically, it assigns the default namespace for the elements of the given XML file. It has nothing to do with the XML schema that happen to be described in that very file. It is just convention for that XML file (no matter what it contains).
The targetNamespace
, on the contrary, is the thing of XSD language itself.
It specifies, which namespace the XML elements described by the schema will belong to.
There is some redundancy between targetNamespace
and xmlns
indeed.
But there is no way to use (harness) it, so as to eliminate one of them. Just think this:
XML will be parsed and converted into something else (e.g. XML infoset) by an XML parser. Such a parser is not required to know anything about XSD and its output won't be XML. So, all XML specific things will be lost (that is xmlns
, namespace prefixes etc).
Then, that infoset (or something else) is passed to the XSD processor, which starts from anew, and it must have all the necessary information at hand. So, the targetNamespace
will be the only thing to tell it about the target namespace of that XML schema!
Best Answer
targetNamespace is an XML Schema "artifact"; its purpose: to indicate what particular XML namespace the schema file describes.
xmlns - because the XML Schema is an XML document, it is then possible to define a default XML namespace for the XML file itself (this is what xmlns attribute does); the implications are multiple: authoring, and composition. For example, one does not have to use a prefix for the items defined in the schema, that are later on referenced elsewhere in the same file (e.g. a global simpleType used as a type for an attribute or element).
From my experience, many XML Schema authors consider this as a "best practice"... so you're on the right track.
In terms of XSD, the targetNamespace prescribes the namespace part of a qualified name of a schema component, which includes elements, attributes, groups and attribute groups, and simple and complex types. Some of the qualified names defined in an XSD (elements and attributes) are "directly" used by an XML instance document. Others, such as for types, can be referenced through the xsi:type attribute in instance XML documents. The rest (groups, attribute groups) are there to facilitate schema composition (through references).
I'm also of opinion that (in general) people come at designing XSD from two angles:
to match an existing XML. In this case, if your XML uses namespaces, for each of the namespaces used, you'll end up with an XSD schema element with a matching targetNamespace attribute.
pure modeling. You then think of targetNamespace similar to an UML package, or database schema, or a Java package, or a .NET namespace, and all it means in this case. Fundamentally it is a mechanism to avoid naming collisions; nonetheless, it is also a mechanism to partition models in subject areas, etc.