Artificial Intelligence, XML, and Java Concurrency

By Roger F. Gay
Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)
It's like XML, but you can store source code in it.
Source code that will be processed as XML in automatic programming applications is created and maintained as XPL (eXtensible Process Language). XPL is structured just like XML, but the parser allows XML's special characters (<,&,>,",') in text elements. This provides a distinct advantage when dealing with source code. Running the transformation to XML concurrently is one of the tactics used to eliminate the performance cost of preprocessing.

Background

The High Level Logic Project began with thought experiments in the early 1980s that were motivated by bottlenecks and performance issues in the first large-scale artificial intelligence commercialization efforts. The result is a very high level framework, written in Java, for simplifying development of high-performance intelligent distributed systems. The project is now in its early commercialization stage.

XML has been a critical technology in the project. For example; software component re-usability is encouraged by allowing customization through configuration rather than rewriting programs. (Like configuring server applications.) And as in many modern projects, XML is also used to communicate between distributed systems. XML processing is well-supported in popular programming languages and familiar to a large number of professional programmers; critical considerations in developing a commercially viable framework. Using XML as much as possible also means re-using processing components more often, contributing to a fast, efficient, light-weight system that is easier to build and maintain.

AI and XML

Artificial intelligence processing quite often involves treating logic as data. This allows a program to “think about” what it's doing, so to speak, and make changes on the fly. In some cases, this involves actually storing source code snippets as text data, configuring its use on the fly, and then either interpreting the code or pushing results into an automatic programming process that compiles.

XML is almost a perfect match for storing code snippets as text. Aside from being well-supported and familiar, tag names can match handler cases, namespaces can instantly deal with some elements of context, and attributes can provide information on special processing requirements (types, etc.) among other things. It would be great then to store source code snippets in XML text elements. But that runs us directly into XML's special character handling problem.

Source code is packed with the “special characters” (<,&,>,",') that XML reserves for XML related processes. XML was designed for markup, not code storage and processing. We need something more convenient; something that allows source code storage in its common, unmodified form without making files bulkier, less readable, or harder to maintain. Yet, for the reasons given, we do not want to abandon XML.

XPL, like an XML for Source Code

Wouldn't it be nice if we had an eXtensible Process Language. XPL would look just like XML, but would not have special character restrictions in text elements. Yes it would, and now it exists. XPL is the High Level Logic Project's solution to the special character problem. XPL looks like XML, but allows special characters in text elements:

<?xpl version="1.0" encoding="utf-8"?>
<mycode xmlns="http://xmlns.hll.nu/rules" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0">
 <state name="dum1" type="int" value="3" />
 <state name="dum21" type="String" value="dum11" />
  <!--  My first rule  -->
  <rule>
    <if> dum1 <5 && dum1 > 1 || dum1 < 200;</if>
    <then>
      dum21 = "Unescaped special characters like '<' can be used."
    </then>
  </rule>
</mycode>

XPL processing uses a pull parser, in a process called StAX-PL (Streaming API for XPL) because it's like XML StAX (Streaming API for XML). Like StAX, StAX-PL is very fast and light-weight. StAX-PL is actually lighter than StAX because it supports fewer features. In simple processing, XPL can be used in place of XML. When full-featured XML processing is needed, StAX-PL is a preprocessor that produces valid XML. We almost have the best of both worlds then. We can store source code in XML structures without facing project crushing inconvenience.

Preprocessing in No Time Flat!

Performance issues have been a serious burden in wider use of artificial intelligence technologies. “Thinking” about thinking, reformulating, adapting on the fly. The additional complexity of AI can seriously slow things down. Commercial grade AI needs to both fit in with common systems development and perform competitively. Processing speed is a constant concern. XPL gives us the data form we need, but at the cost of additional process time. StAX-PL is very fast, but there are ways to eliminate the cost altogether.

In many cases, it will not be necessary to carry out preprocessing during live runs. If there is no reason to change the initial code data during a live run, then the valid XML can be generated beforehand. No need to burden the live run with preprocessing. In some of the automatic programming cases, not even the XML files are needed. Compiled programs are used during live runs. The process from XPL to compiled code is part of development (automatically done by the HLL development engine).

It seems as though the most common cases are likely to occur during development, maintenance, and end-to-end testing. Frameworks are created in the service of those activities, so this is reason enough to take extra steps to speed things up. Tool builders must also respect the fact that application developers and operators make final judgments about how things are run. Flexibility counts. We can take it as a general rule that speed is a good thing. (The project is also involved in use cases that incorporate real-time updates, but this is best left to a separate discussion.)

Using Java Concurrency

StAX-PL uses a pull parser. SAX uses a push parse process, in which input is pushed onto the SAX processing stack. These two processes work well concurrently. StAX-PL very rapidly pulls elements from the XPL parser and pushes them onto the SAX stack. Because the job StAX-PL does is limited, it is not difficult to keep ahead of heavier SAX processing. Even if the demands on SAX are relatively light, StAX-PL (like XML StAX) is quite competitive when it comes to speed.

The Java language and the JVM were designed to support concurrent programming. The technical details of the HLL implementation for Java 7 and Java 8 are not unique except in the use of StAX-PL as the initial source. The StAX-PL and SAX processes are run in separate threads with output from StAX-PL piped directly to SAX. (PipedOutputStream -> PipedInputStream)

Typical programmer timing estimates were made on an Intel dual core computer. System time in milliseconds was recorded before processing began and after it was complete. Tests included multiple runs in order to filter out system state differences. Separate times were taken for a complete (read process write) StAX-PL process and a complete SAX process and then compared with the concurrent StAX-PL / SAX process.

SAX processing was limited and approximately equivalent to StAX-PL processing. StAX-PL read and parsed the XPL file and piped elements to SAX. SAX received the valid XML elements in its stack, re-parsed them, and wrote summary information. All three processes (StAX-PL alone, SAX alone, and both together) took nearly exactly the same amount of time, confirming the success of Java concurrency in eliminating the performance cost of preprocessing.

About StAX-PL

An XPL developer suite is available from the High Level Logic Project. The suite includes source code for XPL processing and quick start source code for XML StAX, SAX, and DOM. The source code for concurrent StAX-PL / SAX is also included.

A FREE XPL command line tool is also available that produces a valid XML file from an XPL file.