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.

A Universal XML Software Pattern

XML is essentially a language used to define complex data by decomposing it into meaningful parts and then arranging the parts in a hierarchical structure. This hierarchical structure is what computer scientists refer to as a “tree.” For example, as shown in the above diagram, a book could be defined as a bunch of data that is composed of chapters, with the chapters, in turn, composed of paragraphs. The complete book could be defined by further decomposing the paragraphs, sentences, and phrases into words.

While this example is relatively simple, XML can more usefully be used to define complex numerical data that is being transmitted between various application programs. The XML allows each application program to interpret the meaning of the data without ambiguity. Financial reports, such as balance sheets and income statements can be decomposed into parts that represent the company’s assets, expenses, and revenues. Each of these parts could be further broken down into parts that represent various categories of those items. The real value of this use of XML is that, while humans can interpret the items in a financial report by their relative positions on paper, a computer program requires the exacting definition that only be provided by a hierarchical structuring like that provided by XML.

So, the key to utilizing XML is to take the unambiguous data interpretation that is provided by the hierarchical tree structure of XML and convert it into a parallel hierarchical tree structure in the application programs’ native languages (i.e. Java or C++). The XML data needs to be applied to variables inside the program, and, because the tree structure represented by the XML document represents the ultimate meaning of the data, the program will need to at least begin its interpretation of the XML document with its internal variables arranged in a hierarchical structure that parallels the XML document.

The question then becomes, “Can we write a single program module that will work for all XML documents and all application programs, regardless of the complexity of the XML?” Can we write software that is reusable across many programs and all XML documents that will interpret the document and make its data available in a hierarchical tree of variables internal to the application programs?

The answer to these questions is a positive one, and in following blog posts here I will show how it can be done in any programming environment that supports object-oriented design. The solution will involve the application of three common design patterns that are standard across the object-oriented design universe and can be implemented in Java, C++, C#, various scripting languages, or any other object-oriented language. This simple but powerful solution and the patterns that it uses will be detailed in the posts that immediately follow this one.

1. XML for Business Intelligence

Much sooner than later, every company will have to do business the XML way, or it won’t do business at all.
Robert H. Hertz, E. Mary Keegan, and David M. H. Phillips, The Value Reporting Revolution

XML (an acronym for “eXtensible Markup Language”) is not a programming language, and, despite its name, it is not just a language for “marking up” documents. XML is a way of expressing the meaning of information – XML provides us with an unambiguous way of expressing the semantics of data that we can communicate to another person or machine.

It is the ability of XML to communicate meaning to a computer, however, that makes it a revolution whose time is inevitable. Human readers have the ability to derive meaning for data from the position or format of a report. Columns represent categories, rows allow the data to be linked to a person or object, and positions within sentences provide us with textual context for the data. However, machines have a great difficulty in determining visual patterns and require a “markup” language to give data categories, textual context, and the other dimensions of meaning.

XML simply provides us with the ability to attach meaningful tags to pieces of information, allowing a machine that reads that information to detect the critical information. A machine that is programmed to read income summaries from financial statements, get simply scan the document for the “income” tag and read the numbers inside the tag, allowing the machine to find thousands of corporate incomes within minutes.

The intent of this blog is to introduce the reader to the powers of XML in the world of financial information and business intelligence. This is the first post for this blog. In the following blogs we will continue to show how the hierarchical structure of XML allows a document to report orders of magnitude more information than was possible before its inception. See Banking the Past, page 180.