Written by nitinpai on September 19th, 2007
Understanding XSD Namespaces With Concepts of Java
This article is aimed at developers who are good at programming languages like Java and want a quick jump on the XSD bandwagon by understanding some important concepts like namespaces. Hope that this article helps to make you understand namespaces quite easily.
What is a namespace?
A namespace is an identifier for elements. XML and XSD use the concept of namespaces to define a relationship between the elements and their hierarchy. It means that when their are multiple elements to be defined then it might be possible that some of the elements may tend to have the same name. But having the same name often leads to collision just as the in the case of classes with same names although in different packages but referenced by name alone in a Java program. Hence the concept of namespaces is used in order to distinguish such elements.
Why are namespaces used?
XML and XSD are never meant for human reading. You have to remember that even though XML is a data representation markup language, it would be rare that you will actually be parsing through an XML file to use the data in your application through your own code.
Such parsing is often supplied through the use of API’s like SAX, DOM, JAXB, etc. You would have till now actually used these libraries while dealing with web services since it is field which uses XML, XSD to the maximum. The concept of namespace has no relevance until and unless an XML instance is associated with an XML Schema (XSD). This is because, XSD defines what do the elements in the XML instance actually mean. A standalone XML just makes the data easier to understand to you but to an XML parser it is nothing but a set of elements in some heirarchy.
For example if suppose you have the following XML format:
From this an XML parser can list out that the XML instance contains 2 elements in which employee is the root and name is the child of employee. It cannot say anything more than that. For giving more meaning to the elements, XML Schema or XSD should be provided. If you want the parser to know what kind of element employee is then you would have to provide a namespace for the element to be in as follows:
How to interpret namespaces?
In an object oriented language like Java, entities of the real world are mapped to Beans. Beans have properties. And in general every application uses the beans and their properties to provide values which are taken from either a system or an end user. Such values when needed to be transferred in the XML format need some kind of hierarchy to be structured with. For this API’s come to the rescue.
But before we can supply the API with the elements in any adhoc fashion it becomes necessary that we make the API aware of the structure by providing it with the Schema without which the API won’t be able to tell you if anything has gone wrong in the hierarchy or not. Such API are said to be namespace aware API’s.
For Example, if I have an bean inside a package which is to be included into any program then you would include it when required as:
//and then make the bean as
MyBean bean = new MyBean();
Now you can refer to the classes within the package successfully.
Comparing the above to namespaces consider the example.
Here tt would be an prefix to the elements which has the value of the entire URL and it would correspond to the namespace just as a package in Java and employee would be an element just as the MyBean in Java. If you would not have provided the packages then the Java program would have given out an error. Similarly in a namespace aware XML parser if you don’t specify the namespace of the element then it would not run successfully.
java.lang.* is the default package of core java. Comparing with a XSD the default namespace is:
Here xsd is in the default namespace i.e. the element xsd is an element of the XSD specification. So now we can say that as java.lang is the default package of java similarly the above namespace is the default namespace of XSD. And as Object is the parent of the Java classes the element xsd is the root of the XSD specification
Custom and Target Namespaces
There are libraries in Java, which may / may NOT be required. Library means something which you can refer to when required, else not. So including it unnecessarily as a inherent feature may be disturbing since they are present for specific reasons and not to be imposed as an implicit feature of the language. Consider this example:
Woops, now here is an error. The element employee is NOT an element of the XSD specification. If you have an XSD validator it will blurt out with a big error message. This is because the XSD specification does not know a thing about your custom element employee. So what do you do? Somehow you should keep your employee in a safe and secure place where it can be recognized as yours. So we can keep it under a custom namespace like “http://techtracer.com/schemas/employee”. So the change required in the above fragment would be as follows:
<xsd xmlns=”http://www.w3c.org/2001/01/XMLSchema” targetnamespace=”http://techtracer.com/schemas/employee”>
So now when the XSD validator comes across the element employee, it just checks if you have told it where it should belong (before starting the ritual of swearing at you!). Now it knows that you have mentioned a thing called targetnamespace. So it knows that your employee actually belongs to a separate specification which is nothing but your custom XML Schema. The new URL which is mentioned in the targetnamespace is your custom namespace itself.
Hope that this article helps to make you understand namespaces quite easily. Feel free to ask a question if you have any doubt about namespaces. Your query will be solved at the earliest.