Three Schema Design Approaches

Article reference from :   http://technologyandleadership.com/three-schema-design-approaches/

In a project where multiple schemas are created it is critical to decide which namespace design approach is suitable for the project: (1)should we give each schema a different targetNamespace, (2)should we give all the schemas the same targetNamespace or (3)should some of the schemas have no targetNamespace. To make this critical design decision, let me illustrate the three schema design approaches in this article.

Heterogeneous Namespace Design

1. Give each schema a different targetNamespace
2. If required to re-use another schema in the current schema we need to import it

Benefits
1. Maximise the re-use of the types with separate namespaces
2. Namespace mapped to domain specific service
3. It would be easier to model all the domain-specific types in separate files with individual namespaces
4. Easier to understand
Drawbacks
1. There will be a large number of namespaces to manage
2. There will be a large number of namespaces to import
3. The granularity of the types in import would depend on the types defined and exposed in a particular domain-specific XSD

Homogenous Namespace Design

1. Give all schemas the same targetNamespace
2. As the schemas have the same targetNamespace, the method of accessing components is “include”.

Benefits
1. No need to either import a service or schemas
Drawbacks
1. Need to handle Name collisions
2. Generate code in a single Java package, for a service
3. chances for redundant types
4. does not allow for domain-specific namespaces

Chameleon Namespace Design

Give the main schema a targetNamespace and give no targetNamespace to the supporting schemas. The no-namespace schemas will take-on the targetNamepspace of the main schema.

Benefits
1. In this scheme, schemas are able to blend in with the main schemas that use them
2. Ability to provide application-specific namespace to the schema
Drawbacks
If the schema <include>s multiple no-namespace schemas then there will be a chance of name collisions. In fact, the schema may end up not being able to use some of the no-namespace schemas because their use results in name collisions with other Chameleon components

The most widely used schema design approach is heterogeneous schema design approach. Let me illustrate this with an example.

Step1: Create a schema file named Books.xsd

Step2: Create another schema file Sales.xsd

Step3: Import the two schema files in Catalog.xsd file

<!--using the Heterogeneous namespace design approach-->
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:b="tns:Books" xmlns:s="tns:Sales" xmlns:ns1="tns:Catalog" targetNamespace="tns:Catalog" elementFormDefault="unqualified">
	<xsd:import namespace="tns:Books" schemaLocation="Books.xsd"/>
	<xsd:import namespace="tns:Sales" schemaLocation="Sales.xsd"/>
	<xsd:element name="Catalog">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element name="Payment">
					<xsd:complexType>
						<xsd:sequence>
							<xsd:element name="CustomerID" type="xsd:integer"></xsd:element>
							<xsd:element name="PaymentType" type="xsd:string"></xsd:element>
							<xsd:element name="Currency" type="xsd:string"></xsd:element>
							<xsd:element name="ShippingAddress" type="xsd:string"></xsd:element>
						</xsd:sequence>
					</xsd:complexType>
				</xsd:element>
				<xsd:element name="Book" type="b:Book" maxOccurs="unbounded"/>
				<xsd:element name="Sales" type="s:Sales" maxOccurs="unbounded"/>
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>
</xsd:schema>