XInclude-Introduction and Usage

Being in the software development field, regardless of functional domains, we all are aware of the power of XML (Extensive markup language) as a communication medium (more precisely, a data describer) for various components of a software application. There are rare applications (product or solution software) in modern software development that are untouched by XML. There has been a tremendous amount of acceptance of XML as an industry-based standard in recent years.

XML is basically a set of specifications that propose how to describe data as per a standardized syntax. We can logically group these XML specifications into the following two categories:

• Primary (basic) specifications—for example, XML Namespaces, XML Information Sets, XML Base, and so forth.

Primary specifications provide the guidelines/rules for XML users/developers to build basic XML documents without any advanced features.

• Advanced specifications—for example, XPath, XLink, XPointer, XInclude, and so on.

Advanced specifications facilitate various advanced features of XML which are built on primary specifications.

Note: This logical categorization is done by the author to explain the scope of specifications. This is not documented/said/approved by the XML standard bodies.

The aim of this article is to state the problem of the industry while using XML with more flexibility. We'll then introduce the XML Inclusion (widely referred as XInclude) specification and explore how it addresses the issues of XML users. An attempt to explore the areas for the usage of XInclude has also been done at the end of this article. Please note that the discussion on the processing module of XInclude and its implementation are not in the scope of this article.

Prerequisite for Readers

People reading this article should be aware of XML. I also assume the readers' familiarity with XML notations and primary specifications. The various XML specifications can be seen at http://www.w3.org/TR/.

Problem Statement

Note: The below-mentioned scenario should be considered as a use-case to understand the issues of XML users in the industry. There are a number of situations in varied domains where this problem is being faced. We will discuss some other cases in the "Usage Areas of XInclude" section at the end of this article.

Let's consider a generic problem of system configurators. When a software system (or application) comes up, there are certain initial configurations required to initialize it. Based upon these configurations, a system will make all its components up and running to serve its clients. Nowadays, this system configuration is widely done in XML, thanks to its extensibility and wide acceptance in the industry.

Now, consider the following scenario where a system has various components and each component has its own configuration, as shown in the following figure:

Click here for a larger image.

The scenario could be more complex because these components might be interdependent in terms of their configurations. Now, the administrator of the system wants to initialize and start the system with various configurations of its components. So, the way he/she does this by building all the configurations of components at one centralized place. This centralized place is nothing but an XML file, which has separate information sets corresponding to each component of the system. This approach has the following pros and cons:

Pros:

• All the configurations are maintained in one centralized XML file.
• Configurations are easy to maintain.

Cons:

• The centralized XML file grows drastically in size when more components or configurations of existing components are imparted to the system, thereby lowering the maintenance of the system.
• The individual configurations of components cannot be reused because they are parts of a centralized XML source.

In summary, in the case of prolonging the system, it's not easy to maintain the centralized configuration system and the configuration doesn't remain neat.

Solution

Thus, the issue is to design a configuration system that exploits the benefits of a centralized XML configuration. At the same time, it should resolve the cons of above-mentioned scenario.

To do this, we need a design that is both centralized and distributed (in our use-case, it is a configuration framework). By creating such a design, we'll have a centralized place where we will have entries for all the components of a system and the distributed framework will have the responsibility of the configurations of individual system components.

This approach is called "providing modularity and reusability to the system."

The following figure shows a high-level view of the solution:

Click here for a larger image.

With this figure in mind, let's introduce the XInclude specification.

Introduction to XInclude

XInlclude addresses the issue explained in the "Problem Statement" section, and provides the flexibility explained in the "Solution" section.

Standard excerpt (taken from http://www.w3.org/TR/xinclude/): Many programming languages provide an inclusion mechanism to facilitate modularity. Markup languages also often have need of such a mechanism. This specification introduces a generic mechanism for merging XML documents (as represented by their information sets) for use by applications that need such a facility. The syntax leverages existing XML constructs: elements, attributes, and URI references.

The XInclude specification specifies the processing model for the mechanism of the XML inclusions. This means that the XInclude processor includes various XML information sets into the source information set and provides the resulting information set as an output. This resulting information set will contain the source information set and all other included/merged information sets. These XML information sets can be anywhere on the network, provided they can be made available to the XInclude processor. The XInclude specification makes full use of namespace and XML base specifications.

This inclusion mechanism can be explained by the following figure:

Click here for a larger image.

This resulting information set can be treated as an input to the system for processing. This processing is of varied types, depending upon the system. For example, in the use-case introduced in this article, the resulting information set will be sent to the configuration framework for initialization and starting up the system.

Example of XInclude

The following is the excerpt of the source information set:

<Services xmlns:xi="http://www.w3.org/2001/XInclude">
  <xi:include href="service1.xml" parse="xml"/>
  <xi:include href="service2.xml" parse="xml"/>
</Services>

service1.xml file:

<Service1>
  <!-This is the comment line in service1.xml file. -->
<Element1 name="element1"/>
</Service1>

service2.xml file:

<Service2>
  <!-This is the comment line in service2.xml file. -->
<Element2 name="element2"/>
</Service2>

After XInclude processing, the resulting information set will look like this:

<Services xmlns:xi="http://www.w3.org/2001/XInclude">
  <Service1>
    <!-This is the comment line in service1.xml file. -->
<Element1 name="element1"/>
</Service1>
  <Service2>
    <!-This is the comment line in service2.xml file. -->
<Element2 name="element2"/>
</Service2>
</Services>

The above example is self-explanatory.

Usage Areas of XInclude

As explained earlier, XInclude is a solution to provide the modularity of a system having various components and reusability of data of those components. Further, we can see the usage of XInclude in the following areas:

• As explained in our use-case, XInclude can effectively be used in a configuration framework of varied software systems.
• XInclude has vast scope in the distributed scenarios where various components of a system are running across the net and there is one centralized place that has the information about the location of the data of components. Now, XInclude is useful in merging the XML data of different components at the centralized place.

Note the usage areas explained above show the high-level view of the scenario. The functional and domain level areas can be inherited from these scenarios to identify the needs of XInclude.

Summary

This article explained the motivation and need to introduce XInclude as an XML specification. We, then, went through the introduction and high-level overview of XInclude.

At the end, the possible use-case scenarios are mentioned to help the readers identify the areas where they can apply the concepts of XInclude.

Acknowledgement

The author acknowledges the valuable review comments of Mr. Mayank Khare (Associate System Analyst, HP, India) in making this article more useful for the readers.

About the Author

Manoj Seth is a senior software engineer at Hewlett-Packard, India. He is a Post Graduate from the Indian Institute of Information Technology, Bangalore.

Manoj has been involved in designing and developing J2EE-based solutions over various platforms in the domains of Financial/Banking and Middleware for more than two years. He has good exposure to Web Services and their emerging standards in development/deployment and management space. Currently, he is working in the telecommunication domain.

He can be contacted at manojseth_2000@yahoo.com.