How to Design a General Rule Markup
Language∗
Gerd Wagner
Eindhoven University of Technology, Faculty of Technology Management
P.O. Box 513, 5600 MB Eindhoven, The Netherlands
G.Wagner@tm.tue.nl
http://tmitwww.tm.tue.nl/staff/gwagner
A General Rule Markup Language has several purposes. It may serve as
a lingua franca to exchange rules between different rule systems and rule
components in application software. It may be used to express derivation
rules for enriching XML/RDF-based taxonomies (also called ‘web ontologies’)
by adding definitions of derived concepts. It may be used to publish the
reactive behavior of a system in the form of reaction rules. And it may
be used to provide a complete XML-based specification of a software agent.
Further uses may arise in novel web applications. In this paper, I consider
the problem of how to design a General Rule Markup Language that can be
used for these and for future emerging purposes.
1 Introduction
Rule markup languages, that allow to express business rules as modular, stand-alone
units in a declarative way, and to publish them and interchange them between different
systems and tools, will play an important role for facilitating business-to-customer (B2C)
and business-to-business (B2B) interactions over the Web.
This paper discusses the question of how to design a general rule markup language,
based on the initial experiences made with RuleML 0.8, a preliminary standards proposal
by the RuleML Initiative [Rul]. Given the great diversity of rule concepts and existing
rule languages, such a language will consist of several overlapping sublanguages which
∗A preliminary version of this paper has been presented as an invited paper at the workshop XML
Technologies for the Semantic Web (XSW2002) held at the Humboldt University of Berlin, Germany,
in June 2002.
1

share a common metamodel. The development of this rule metamodel is a difficult
conceptualization and integration problem.
The paper is organized as follows: section 2 contains a brief survey on rule technolo-
gies, section 3 discusses the problem of an abstract syntax, section 4 presents use cases,
design goals and requirements for a general rule markup language, and section 5 gives a
brief introduction into RuleML.
2 Rules in Today’s IT Landscape
2.1 Business Rules
Business rules refer to the hundreds, if not thousands, of policies, procedures and defini-
tions that govern how a company operates and interacts with its customers and partners.
They represent the knowledge a company has about its business. Typically, a company
does not maintain an explicit list of all its business rules. Rather these rules are implicitly
expressed in documents about things such as corporate charters, marketing strategies,
pricing policies, and customer relationship management practices, as well as in contracts
and other legal documents. They are also implicitly expressed (or ‘buried’) in many
pieces of program code distributed across the client, application logic and database tiers
of modern business application systems. It is the task of requirements engineering and
domain analysis to capture all these business rules that are at the core of functional
requirements.
The term business rule can be understood both at the level of a business domain and
at the operational level of an information system. The more fundamental concept are
business rules at the level of a business domain, captured in the form of natural language
statements. In certain cases, these statements can be operationalized by transforming
them into executable rule expressions, preferably in a declarative rule language. In
other cases they cannot or don’t have to be operationalized and automated, but are only
expressed in natural language for the purpose of communication and documentation.
It follows from these remarks that a GRML should allow to express rules both in
natural languages and in declarative executable languages.
Three basic types of business rules have been identified in the literature (see [TW01]):
integrity rules (also called ‘integrity constraints’), derivation rules (also called ‘deduction
rules’ or ‘Horn clauses’), and reaction rules (also called ‘stimulus response rules’, ‘action
rules’ or ‘event-condition-action (ECA) rules’). A fourth type, deontic assignments, has
only been marginally discussed (in a proposal of considering ‘authorizations’ as business
rules).
An integrity rule is a an assertion that must be satisfied in all evolving states and
state transition histories of an enterprise viewed as a discrete dynamic system. There
are state constraints and process (or behavior) constraints. State constraints must hold
at any point in time. An example of a state constraint applied by a car rental company
is: The driver must be at least 25 years old. Process constraints refer to the dynamic
integrity of a system; they restrict the admissible transitions from one state of the system
to another.
2