Cover Pages: Simple Rule Markup Language (SRML)

[May 17, 2001] A communiqué from Margaret Thorpe (ILOG, S.A.) announces the development SRML (Simple Rule Markup Language) which the designers believe may be of wider interest. SRML describes a "generic rule language consisting of the subset of language constructs common to the popular forward-chaining rule engines. Because it does not use constructs specific to a proprietary vendor language, rules specified using this XML DTD can easily be translated and executed on any conforming rule engine, making it useful as an interlingua for rule exchange between Java rule engines. The Java Rule Engine API specified in JSR-000094 defines generic API support for parsing rulesets that are represented using XML, but does not define a rule language standard. Thus, while JSR-094 will prescribe that some kind of 'content language' is made available to the engine via XML, and will provide some kind of 'content handler' to process these XML rule documents, a rule language is still required in order to provide a Java rule engine with rules via this API." A preliminary XML DTD describing the structure of SRML has been made available by the authors. As defined in this DTD, a ruleset "is the root element of the SRML XML document, and it consists of a list of rules. Rules have a condition part [conditionPart] and an action part [actionPart], and the condition part must have at least one condition. Conditions are composed of test expressions, and can be simple conditions or not conditions." Etc.

Background excerpted from "Simple Rule Markup Language (SRML): A General XML Rule Representation for Forward-chaining Rules," by Margaret Thorpe and Changhai Ke, ILOG, S.A.:

"Over the last few years, forward-chaining rule engines have become increasingly popular tool for implementing business rule applications - applications where the business logic (business rules) is very dynamic and must be externalized for management by non-technical users. With the huge migration of business applications into the Web environment, and the demand for customization and personalization capabilities in online offerings, rule engines are powering a whole new breed of business rule application. In addition to supporting the definition of business policies by non-technical users in business rule languages, these applications enable users to personalize their preferences for everything from content to navigation, and they enable product or service providers to customize their offerings and interaction with customers based not only on customer preferences, but on customer profiles and historical activity (prior purchases, etc.).

"As rule engines become more common in the Web environment we are seeing J2EE application server and commerce server vendors adding rudimentary rule capabilities to their eCommerce platforms. In accordance with the J2EE promise of portability, J2EE-compliant vendor offerings are by their very nature interchangeable. So, for example, a J2EE-compliant application (developed using standard J2EE services) should be able to run on any application server - not just the one that it was developed on. Through the standardization of APIs via the Java Community Process, and the compliance-testing of vendor products using the compatibility toolkits, companies building Enterprise applications are ensured protection from reliance on a single vendor and proprietary interfaces and languages are becoming less and less appealing. This philosophy is extending itself to Java rule engines, evidenced by the launch of a JSR (Java Specification Request) earlier this year to define a standard Java API for rule engines.

There are several commercial Java rule engines on the market right now (ILOG JRules, JESS, OPS/J, Blaze Advisor) with different feature sets. They each have their own set of Java APIs, and they each have their own proprietary rule language. As a result, rules cannot be shared across applications that use different rule engines, and applications developed using these rule engines remain tied to a specific vendor implementation. This is somewhat similar to the situation that existed with RDBMs before JDBC was adopted with its standard API that isolates developers from different vendor RDBMS implementations. JSR-094 has been introduced to accomplish a similar objective with respect to Java rule engines.

"JSR-094 defines a Java runtime API for rule engines targeting both the J2EE and J2SE platforms. The API prescribes an object model and a set of fundamental rule engine operations based upon the assumption that most clients will need to be able to execute a basic multi-step rule engine cycle. The fundamental rule engine operations to be supported are: parsing rules, adding objects to an engine, firing rules and getting resultant objects from the engine. The API will probably also support variations of this basic cycle that would occur in J2EE server deployments (multiple instances of rule engines, the sharing of rulesets between different instances of a rule engine, the ability to reset and reuse an instance of a rule engine, etc.) A primary input to a rule engine is a collection of rules called a ruleset. The rules in a ruleset are expressed in a rule language. JSR-094 defines generic API support for parsing rulesets that are represented using XML, but does not define a rule language standard.

[Solution:] "An XML Rule Representation for Java Rule Engines. We propose an open, XML-based rule language that we plan to contribute to the community by registering the schema on xml.org... Simple Rule Markup Language (SRML) describes a generic rule language consisting of the subset of language constructs common to the popular forward-chaining rule engines. Because it does not use constructs specific to a proprietary vendor language, rules specified using this DTD can easily be translated and executed on any conforming rule engine, making it useful as an interlingua for rule exchange between Java rule engines. The ruleset is the root element of the SRML XML document, and it consists of a list of rules. Rules have a condition part and an action part, and the condition part must have at least one condition. Conditions are composed of test expressions, and can be simple conditions or not conditions. Simple conditions can be bound to variables while not conditions cannot. The action part of a rule consists of actions, which can be variable declarations and assignments, as well as the traditional assert, retract and modify statements of rule languages. The assert action adds an object to working memory. The retract action removes an object from working memory. The modify action modifies an object in working memory. Expressions appear throughout the language and can be assignable (variables or fields), constants (literals such as strings, ints, floats, booleans, etc.), arithmetic or boolean expressions.

References:

XML DTD for SRML (Simple Rule Markup Language): HTML format and plain text format.
ILOG Simple Rules DTD with annotation in comment declarations: HTML format and plain text format
Simple Rules DTD - Hypertext view
Sample markup
Contact: Margaret Thorpe (ILOG, S.A.)
ILOG, S.A. web site
See also: JSR-000094 Java Rule Engine API
See also: "Rule Markup Language (RuleML)"
See also: Business Rules Markup Language (BRML)
See also: DARPA Agent Markup Language (DAML)
See also: Predictive Model Markup Language (PMML)


SEARCH \| ABOUT \| INDEX \| NEWS \| CORE STANDARDS \| TECHNOLOGY REPORTS \| EVENTS \| LIBRARY