A Universal XML Software Pattern, Part IV

There already exists a framework for inserting XML in programming languages such as Java and C++. It is known as DOM (Document Object Model). DOM and its variations, however, work at a very low level that assists reading of the document into our program but which proves insufficient to convert the XML data into objects that are meaningful to our applications. Each component of the XML document is parsed by DOM and turned into an object of the type “Element.” Since the Element class has no relationship to the application programs that are being developed, it offers no effective “methods” or activities that would help our programs process information. To fully utilize XML, DOM Element objects must be converted into a Composite pattern made up of objects that are both an integral part of our program and a functional component of a universal tree data structure.

The DOM model is not really a true reflection of the XML document. The XML document is made up of objects, arranged in a hierarchy, that belong to different classes or categories with different meanings based upon the object’s membership in those classes or categories. XML may actually format each of these objects into syntactical units called elements, reflecting the DOM model, but the different elements of XML actually have separate classes with class behaviors and meanings based upon the element’s tag name. Syntactically, the DOM programming model may be a reflection of the XML document, but semantically, representing the true meaning of the data, the Element objects of DOM are empty and need the object-oriented classes of our application programs to give them life. The DOM model works for all XML because it does not involve itself in the meaning of the data, only the syntax. Our Composite framework, on the other hand, must allow for the giving of meaning to the information.

The actual building phase of our Composite pattern involves converting a tree of primitive Element objects into a tree of objects that are meaningful citizens of our application programs.
This, in a nutshell, is our challenge: how do we best design a framework that allows our objects in the Composite tree to have the meaning that our programs need to solve particular problems while still requiring them all to have the common interface that is necessary to organize them into a Composite tree? We need to design a way to allow classes of objects to be organized into a Composite tree without requiring each of these perhaps thousands of classes of objects to have the Composite pattern interface.

To support the Composite tree, each object in the hierarchy needs to have the interface designed in the previous post here, but, to give our Composite tree a universal application, we need to be able to have it used with objects that know nothing about the hierarchy they are being assembled into and which therefore do not support the Composite pattern’s interface. As a review, this interface, which we will hereafter refer to as the TreeNode interface, has the following methods.

• getParentNode
• getChildrenNodes

To resolve the conflict between universality and the very specific requirements of the Composite tree we again resort to the standard patterns that exist in the world of object-oriented programmers. Specifically, the Adapter pattern, with some modification, will be used to wrap Composite-naïve objects into “wrapper” objects that support the TreeNode interface. In the following post, this design pattern will be further elaborated upon as we continue to design a universal Composite framework that can be used with any XML document.

A Universal XML Software Pattern, Part III

The creation of a universal XML framework must begin with the Composite pattern. The Composite pattern, the representation of a part-whole hierarchy into a tree structure, is such a powerful model of the many objects that make up our world that it needs to be made into a framework of its own – a Composite framework that can be used to model many other things in addition to XML. As a universal framework, we want our composite pattern to the independent of XML or any other medium of communication. We are not simply solving a particular problem; we are going to convert the Composite pattern into true intellectual capital that can actually increase the value of an IT department.

The Composite pattern is worthy of the effort that goes into a universal framework. As a programming representation of a hierarchical tree structure it is the most fundamental configuration of data in information science. The fact that it is an isomorphic fit to the hierarchical structure that defines XML attests to the universal nature of its utility to the study of information in general.

In later posts to this blog, it will be shown how all of the information found in the financial data now produced by accountants can be expressed simply as a Composite tree that has the ability to easily produce and display the standard financial reports that are used to measure the components of our economy and has the power to vastly expand on the information provided in those reports.

Our framework design begins by defining the classes of objects that interact to support our Composite tree framework. Objects interact by offering each other a set of useful activities. One object calls on of another object’s activities in order to perform steps in the process that is the application program. The definition of each object is made up of the activities that it can perform for the asking or “calling” object. This definition is known as the object’s interface. A certain class of objects (i.e. a class of persons, accounts, departments, etc.) has a common interface that is shared by all of the objects of that class, allowing us to define a whole population of objects that behave similarly according to this common interface.

How many class interfaces need to be defined for the objects that make up our Composite framework and how complicated do their interfaces have to be? The answer is that there only needs to be one interface defined for this framework and that interfaces is a very simple one. Every object in the Composite tree is a node that points at its neighboring objects as is shown in the diagram above. Each node points at a single parent node higher than itself in the hierarchy and any number of child nodes that are immediately below in the hierarchy. To facilitate the program’s navigation throughout the Composite tree, each node has to provide access to these neighboring objects for the parts of the program that “call” its interface. Therefore, each object needs to provide the activities (or, in programming parlance, “methods”) that give access to its parent and children for a part of the program that “calls” it. Logically, we could name these activities as follows:

• getParentNode
• getChildrenNodes

Because of the inherent nature of tree nodes, we can determine that a Composite tree can be fully navigated and utilized when it is populated by objects that satisfy this simple interface. The “getParentNode” method allows us to navigate up the tree by recursively asking each node to give us its parent node. Similarly, we can be navigated downwardly by similarly calling on the node objects’ “getChildrendNodes” methods.

This small simple interface essentially provides us with a Composite framework. The interface can be satisfied by defining classes of objects that all fulfill this interface, and, as we will show in following posts, we can generate a single class of objects that satisfies this interface universally by using the Adapter pattern.