In an xml schema document, if I have both the targetNamespace and the xmlns without a prefix.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://example.com/" xmlns="http://example.com/">
What is the exact difference between them? My comprehension is that if you have an xmlns without a prefix, all elements without prefix gets that namespace and...confusingly the same goes for targetNamespace.
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.
For those who are still confused, consider these three xsds. They all define one global type and one global element definition that references it.
First, an xsd like the one posted above. It uses the prefix 'xsd' for the schema namespace, and a default namespace for the targetNamespace:
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://example.com/"
xmlns="http://example.com/">
<xsd:element name="aGlobalElement" type="aGlobalType"/>
<xsd:simpleType name="aGlobalType">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:schema>
Now the same xsd, but defining and using a namespace prefix for the target namespace:
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://example.com/"
xmlns:tns="http://example.com/">
<xsd:element name="aGlobalElement" type="tns:aGlobalType"/>
<xsd:simpleType name="aGlobalType">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
</xsd:schema>
...and finally, a version that uses a default namespace instead of 'xsd' for the XML schema namespace:
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://example.com/"
xmlns:tns="http://example.com/">
<element name="aGlobalElement" type="tns:aGlobalType"/>
<simpleType name="aGlobalType">
<restriction base="string"/>
</simpleType>
</schema>
Most of the schema authors choose the first or the last, because if the default namespace facility is available then we might as well use it for something.
xmlns
The xmlns attribute sets the default name space of the described element. The default name space is thus applied to all the elements inside the described element, which do not explicitly declare another name space for themselves.
The default name space is set to a standard value for WSDL files: http://www.w3.org/ns/wsdl
targetNameSpace
This attribute contains the name space of your web service. You can choose this name space freely, but there is a convention saying that the URI should point to the WSDL of the service.
xmlns:tns
This name space should be set to the same URI as the targetNameSpace attribute. That way you can refer to the target name space via this name space prefix (tns).
namespace means like scope
targetNamespace is an attribute of schema element defines namespace i.e. package in XSD file. By convention we use URI/URLs, but we could use any string.
xmlns is an attribute is used to refer elements and datatypes that come from xmlns attribute value for the current element scope.
For Example:
xmlns:xsd="http://www.w3.org/2001/XMLSchema" is with prefix as xsd means namespace should be prefixed with xsd:xmlns="http://www.w3.org/2001/XMLSchema" without prefix is default p means namespace should be prefixed with p:Where xmlns:xsd and xmlns:p are QNames and xmlns is local name.
The following image helps to understand XSD using Java analogy as per my knowledge:
Other answers are good here, so I will not repeat their explanations here. However, if anyone from Java background, find its simpler, here is the analogy I came up with -
.xsd document is the artifact/.jar filexmlns is the
package com.example
statement, you declare at the top of your Java classes.
Consider (for analogy), if you had one single package in your Java project, and all the classes are declared and defined within a single outer class. For eg,
package com.furniture.models
public class FurnitureShop {
int noOfTables;
int noOfChairs;
int noOfBeds;
List<Table> tables;
List<Chair> chairs;
List<Bed> beds;
// and now instead of declaring and defining a class for table/chair/bed in a
// separate file, you just add it here
public static class Table {
int height;
int width;
int length;
...
}
public static class Chair {
String color;
ChairType chairType;
...
}
public static class Sofa {
int price;
String color;
...
}
}
This is how different elements are grouped in a single .xsd file, for a new schema.
targetNamespace is the name of the artifact you create. As you can find it out yourself, targetNamespace is used when creating a schema, in an .xsd file.Once, the artifact(or .xsd file) is created, you'd use it in other projects as follows -
In a Java project, you'd import the library, using pom.xml (or build.gradle) file as follows -
<dependency>
<groupId>com.furniture</groupId>
<artifactId>furniture-apis</artifactId>
<version>1.1.1</version>
</dependency>
In XML, you'd "import" the schema using
<furniture xmlns="http://furniture.com"/>
=== APPENDIX ===
Clarification -
xmlns is both used as a package statement, as well as the import statement in Java. In .xsd file, xmlns acts as the "package" statement, whereas in .xml files, it acts as the "import" statement.
After some thorough testing using xmllint I think I found the definite explanation here. Consider the below schema:
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema
version="1.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://yyyzzz.com"
xmlns:p="http://abced.com"
xmlns:q="http://pqr.com"
xmlns="http://yyyzzz.com">
<xsd:element name="recipe" type="recipeType" />
<xsd:complexType name="recipeType">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="desc" type="xsd:string" />
<xsd:attribute name="archetype" type="xsd:string" />
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:schema>
The above schema validates to the below document:
<?xml version="1.0"?>
<recipe xmlns="http://yyyzzz.com">
Deciphering the purpose of targetNamespace
</recipe>
The reason that works is because xmlns="http://yyyzzz.com" automatically binds to the element being defined by the schema too! That means, it binds also to the recipeType element.
Now, with same xml document but with slightly modified schema as below also validates and take a close look at the difference:
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema
version="1.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://yyyzzz.com"
xmlns="http://eigenfield.aparicio.com"
xmlns:EGboy="http://yyyzzz.com">
<xsd:element name="recipe" type="EGboy:recipeType" />
<xsd:complexType name="recipeType">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="desc" type="xsd:string" />
<xsd:attribute name="archetype" type="xsd:string" />
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:schema>
Ignore if the other xmlns gone missing, but instead look closely at type="EGboy:recipeType". We can no longer rely on the xmlns because it has different value therefore, we must put the prefix EGboy in front of recipeType.
The xml document does not even care of the EGboy prefix this prefix is only for the schema to refer to the proper xmlns in case there are many.
