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.
- Advanced specifications—for example, XPath, XLink, XPointer, XInclude, and so on.
Primary specifications provide the guidelines/rules for XML users/developers to build basic XML documents without any advanced features.
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/.
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:
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:
- All the configurations are maintained in one centralized XML file.
- Configurations are easy to maintain.
- 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.
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:
With this figure in mind, let's introduce the XInclude specification.