14. Jess and XML

Jess now supports an XML-based rule language. Rather than adopting an evolving standard like RuleML, Jess's XML rule language (JessML) was designed to be close in structure to the Jess language itself. JessML is a hybrid imperative/declarative language, just like the Jess language itself. That means you can not only write rules in it, but define and call functions as well. Anything you can do in the Jess language, you can do in JessML too.

Transformation between JessML and RuleML and other XML rule languages should be simple using XSLT, and in fact we hope to provide several such translators with the final Jess 7 release.

JessML code is quite verbose. Remember, though, that's it's intended to be easy for machines, not humans, to work with.

• PLANNING::store-plan-data
• MAIN::animal
• make-pair

• <value><type>SYMBOL</type>nil</value>
• <value><type>INTEGER</type>1</value>
• <value><type>STRING</type>A String</value>

<funcall>
  <name>
    +
  </name>
  <value><type>VARIABLE</type>x</value>
  <value><type>INTEGER</type>1</value>
</funcall>
            

<slot>
    <name>
      location
    </name>
    <value><type>SYMBOL</type>nil</value>
</slot>
        

You can define a template in the JessML language using the template element. A template element contains a name element followed by any number of elements. The value elements of the slots are interpreted as default values.

<template>
    <name>
      monkey
    </name>
    <slot>
        <name>
          species
        </name>
        <value>
          <type>SYMBOL</type>
          rhesus
        </value>
    </slot>
</template>

You can also automatically define a template based on a Java class using a from-class property, like this:

<template>
  <name>
    MAIN::button
  </name>
  <properties>
    <property>
      <name>from-class</name>
      <value><type>SYMBOL</type>java.awt.Button</value></property>
  </properties>
</template>

A rule contains a nameelement, a lhs element, and a rhs element. The rhs element contains a collection of funcall elements representing the rule's actions. The lhs element contains groups and patterns, which are somewhat complex, and will be discussed in the following sections. A simple rule might look like this (this rule prints "Fired!" for each "MAIN::button" fact that exists.

<rule>
    <name>
      MAIN::myrule
    </name>
    <lhs>
        <group>
            <name>
              and
            </name>
            <pattern>
                <name>
                  MAIN::button
                </name>
            </pattern>
        </group>
    </lhs>
    <rhs>
        <funcall>
            <name>
              printout
            </name>
            <value><type>SYMBOL</type>t</value>
            <value><type>STRING</type>Fired!</value>
            <value><type>SYMBOL</type>crlf</value>
        </funcall>
    </rhs>
</rule>

You can use a binding element to bind a variable to the fact that matches a pattern. The text of the binding element is simply the name of the variable to use.

A test element represents a single test in a pattern. A test can either be discriminating or nondiscriminating. A discriminating test is one that sometimes matches and sometimes doesn't. A nondiscriminating test is one that always matches; generally this refers to tests that merely bind a variable to the contents of a slot. There's no difference in the syntax between these two types of test.

A test element contains a type element, an optional conjunction element, and either a value element or a funcall element. The type element's body is either "eq" or "neq", corresponding to a positive or negative test. The conjunction element's body can be either "and" or "or", and it is can used only in the second and later tests on a slot. Finally, the value element represents the test itself. If it's a constant, the contents of the slot will be compared to it for equality or inequality, according to the contents of the type element. If the value is a variable, and if that variable has not been bound to a slot, the variable is bound to the current slot. Otherwise, the variable is compared to the contents of the slot. Finally, if there is a funcall element, the function is evaluated and the test passes if the result is true (for an "eq" test) or false (for a "neq" test.)

You can translate a file of Jess language code into XML using Jess's XMLPrinter tool; this is a good way to learn how Jess and JessML correspond. The command to use this tool looks like:

java -classpath jess.jar jess.xml.XMLPrinter myfile.clp > myfile.xml
            

The file "myfile.xml" will be a complete translation of all the code in "myfile.clp", including templates, rules, deffunctions, and top-level function calls.

In general, anywhere you can use a file full of Jess language code, you can also use a JessML file. For example, the file you provide as a command-line argument to jess.Main can be a JessML file.

The standard batch function can read JessML code as well as Jess language code. It decides what kind of file it is looking at by looking for the "<?xml" characters that should begin a well-formed XML file. require, which uses batch internally, will work with JessML as well.

You can get a little bit more control of the process by using the classes JessSAXParser or JessSAXHandler directly. JessSAXParser will parse a JessML document from an InputSource, installing the results into a Rete object you provide. JessSAXHandler is a SAX event handler that you can use with your own parser.