Tag: XML

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

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
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”.

1. No need to either import a service or schemas
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.

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
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

<!-- to store book information with targetNamespace declared as tns:Books-->
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    <xsd:complexType name="Book">
           <xsd:element name="Author" type="xsd:string"/>
           <xsd:element name="Title" type="xsd:string"/>
           <xsd:element name="Price" type="xsd:double"/>
           <xsd:element name="Quantity" type="xsd:integer"/>

Step2: Create another schema file Sales.xsd

<!-- to store the sales information with targetNamespace declared as tns:Sales-->
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    <xsd:complexType name="Sales">
             <xsd:element name="Customer" type="xsd:string"/>
             <xsd:element name="Region" type="xsd:string"/>
             <xsd:element name="TransactionStatus" type="xsd:string"/>

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:element name="Payment">
							<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:element name="Book" type="b:Book" maxOccurs="unbounded"/>
				<xsd:element name="Sales" type="s:Sales" maxOccurs="unbounded"/>

Web services take web applications to the next level. By using Web services, your application can publish its function or message to the rest of the world. With web services, your accounting department’s Win 2k server’s billing system can connect with your IT supplier’s UNIX server.Web services can offer application-components like: currency conversion, weather reports, or even language translation as services. There are things applications need very often. So why make these over and over again?

Web services are units of programmable application logic located on web servers that can be accessed remotely using standard internet protocols and data formats such as XML, HTTP and SOAP.

Web services are platform-independent and language-independent, since they use standard XML languages. This means that my client program can be programmed in C++ and running under Windows, while the Web Service is programmed in Java and running under Linux.

Web Services are published, found, and used through the Web. The basic Web services platform is XML + HTTP.


Web services platform elements are:

  • SOAP (Simple Object Access Protocol)
  • UDDI (Universal Description, Discovery and Integration)
  • WSDL (Web Services Description Language)

XML in 5 Days - A Hands On Approach

Introduction to XML

XML is the universal format for data interchange.  It is supported by all major operating systems, programming languages and development platforms.  It is the standard platform for building interoperable distributed applications. 

The ability to invoke cross platform communications makes the reach of XML Technology unlimited and its use in Web Services compelling.

Web Services are the building blocks for constructing distributed Web-based applications. They are units of programmable application logic located on web servers that can be accessed remotely using standard internet protocols and data formats such as XML, HTTP and SOAP. Web services use XML-based messaging to send and receive data, which enables heterogeneous applications to interoperate with each other.

Basic concepts of XML

 XML represents structured content rather than visual display. A well-formed XML document contains an end tag for every begin tag. Well-formed XML documents can be modeled as trees. The tree has a single root node containing one or more child nodes. A node without a child is called leaf node. XML Document Object Model (XML DOM) is required to work with XML data.

Document Object Model (DOM) 

Document Object Model (DOM) is a representation of the XML document in memory.  It is used to read, write, and manipulate an XML document. DOM loads the entire XML document into memory.

Simple API for XML (SAX) 

Simple API for XML (SAX) is used to read data from XML documents. SAX parser reads the contents sequentially and generates events as it reads the XML document.  It does not load the entire XML document into memory. SAX is good for reading large XML Documents.

Limitations of SAX:  SAX does not maintain any data structures that are required to perform complex searches. They cannot be used to modify the XML document.

Document Type Definition (DTD)

Document Type Definitions (DTD) outlines elements, attributes & relationships allowed in an XML document. DTDs are written in their own syntax rather than XML syntax.

XML Schema Document (XSD)

XML Schema Documents describe and validate the structure of XML documents.  They restrict the value of elements and attributes in an XML document. They are written in XML syntax. An XML document that adheres to XML schema is called Valid XML document. The XML Schema documents have suffix xsd.