Namespace Walk-though Example Namespaces Overview So far in this tutorial we have largely ignored namespaces as they are an added complexity over writing and using basic XSDs. The full set of namespace rules are very complex, be this overview will provide a basic outline of the technology. Namespaces are a mechanism for breaking up your schemas. Up until now we have assumed that you only have a single schema file containing all your element definitions, but the XSD standard allows you to structure your XSD schemas by breaking them into multiple files.
These child schemas can then be included into a parent schema. Breaking schemas into multiple files can have several advantages. You can create re-usable definitions that can be used across several projects. They make definitions easier to read and version as they break down the schema into smaller units that are simpler to manage. Namespace Walk-through Example In this example, the schema is broken out into four files: OrderTypes - this could contain all your definitions for orders.
Main - this would pull all the sub schemas together into a single schema, and define your main elements. This all works fine without namespaces, but if different teams start working on different files, then you have the possibility of name clashes, and it would not always be obvious where a definition had come from. The solution is to place the definitions for each schema file within a distinct namespace.
We can do this by adding the attribute targetNamespace into the schema element in the XSD file: In principle the namespace has no meaning, but some companies have used the URL where the schema is stored as the targetNamespace, and so some XML parsers will use this as a hint path for the schema: So in our example above each of the 4 schema files could have a distinct targetNamespace value.
Let's look at them in detail. We need to do a few things in order to use this. First we need to import that schema into this one - so we can see it. It is worth noting the presence of the targetNamespace attribute at this point. This means that all entities defined in this schema belong to that namespace: In order to do this we must define an alias for the namespace "http: We can now make use of the types within the CommonTypes. When we do this we must fully qualify them as they are not in the same targetNamespace as the schema that is using them: This element builds on the other schemas, so we need to import them all, and define aliases for each namespace.
The element "CustomerDetails" which is defined in main. Let's look at an example: This tells the XML parser that elements within the namespace "http: The next thing we do is define some aliases: The general rules for this are: The alias must be the same as the target namespace in which the element is defined. It is important to note that this is where the element is defined - not where the complexType is defined.
This has two possible values, qualified, and unqualified, the default is unqualified. This attribute changes the namespace rules considerably. It is normally easier to set it to qualified. So to see the effects of this property, if we set it to be unqualified in all of our schemas, the resulting XML would look like this: These general rules now apply: Only root elements defined within a schema need qualifying with a namespace.
All types that are defined inline do NOT need to be qualified. The first element is Purchase, this is defined globally in the Main. So it does not need to be aliased. The same is true for all the child elements, they are all defined inline, so they do not need qualifying with a namespace.
As you can see we have defined this as a global element within the targetNamespace "http: In the element "Purchase" we just reference it.