Kinetic Rule Language

KRL is called an event condition action or ECA rule language because of the roles that those three fundamental parts of a rule play:

• Events – Events trigger specific things to occur. Events are like the trigger of the "gun"—the rule. Without the event to trigger the rule, nothing happens.
• Conditions – Conditions are similar to the safety of a gun. If the conditional expression does not return true, the rule does not fire. Just as a gun either shoots or doesn't shoot based upon the safety, there is no else statement on conditionals. If you want a rule to fire in the opposite case, you can use the not fired postlude to trigger another event, or you can have a rule with a conditional which tests for the opposite case.
• Actions – Actions are like the bullet coming out of the gun; they are the final result of the rule. A rule may have multiple actions.

Besides a collection of rules, KRL rulesets also contain a meta section for specifying information about the ruleset, a dispatch section for providing clues about event salience, and a global section for global definitions. Each rule conforms to the pattern for ECA rule languages given above with some significant additions.

The basic structure of a KRL rule is as follows:

rule <name> {
  select when <eventexpr>
  pre {
    <declarations>
  }
  if <expr> then
    <action>
  fired {
    <effects>
  } else {
    <effects>
  }
}

• Event expressions in the select statement declare the conditions under which the rule will be selected.[6]
• Declarations in the rule prelude allow values to be calculated and store for use later in the rule
• Conditional expressions determine whether a selected rule fires.
• Actions can be either built-in or user defined and specify the action of the rule
• Statements in the rule's postlude (fired...else...) affect persistent variables and raise further events.

KRL events are raised by other rules of event generators commonly referred to as "endpoints". Events are commonly raised over HTTP using a model that conforms to the Evented API,[7] but KRL is transport agnostic. For example, events could be transported by email, SMS, MQTT, or any other system supporting push-style notifications. Because the Evented API is a specialization of the webhook concept, any system that supports webhooks can raise events for KRL.

KRL uses event channels to identify the entity for which the event is raised. An entity can have any number of event channels. Event channels are encoded in the URL for events transported over HTTP.

An endpoint that generates an event may be observing some activity directly and reporting salient state changes or it might just be reporting or transforming event data from another source (e.g., a webhook).

Endpoints are responsible for

• raising relevant events to the event processor,
• responding to directives from the event processor, and
• maintaining state to link separate interactions with the event processor together in meaningful ways to create context.

KRL is a deterministic rule language. This means that KRL programs consist of a set of rules that take an action when triggered. Just as functional, object-oriented, and imperative languages are all different, rule languages also require a different way of thinking. Consequently, writing a KRL ruleset is not a traditional programming task.

At its simplest, a rule is a conditional action. The action can be anything appropriate to the domain. For augmenting web pages, actions are page modifiers. In other domains, the action can be whatever the endpoint can consume. When a rule's action is taken, we say that the rule "fired." Note that the action is conditional: the action is taken only when the rule is selected and its premise is true.

In the first stage, the rule is either selected or not, based on the event pattern in the event expression. The event expression of a rule follows the select keyword in the rule. For example, in the web domain, this most often consists of a regular expression to match with the URL of the page being augmented. Thus, in the first stage the rule is selected only for certain web pages.

The second stage of the conditional firing of the rule is testing its premise, which consists of a predicate that is used to test the context in which the rule is being evaluated. This check is done after the rule's prelude section, where values are declared, so that it has the benefit of any computation needed to create or manipulate the context. The predicate of the conditional is optional, so it is possible to write a rule that always fires because its selector always selects. However, most interesting rulesets will contain rules that only fire under certain circumstances.

The following example shows a simple KRL rule:

rule good_morning {
  select when pageview url #example.com#
  if morning() then
    notify(“Welcome!”, “Good morning!”)
}

This rule would send a “good morning” notification to visitors of any page in the archives of a web site (as denoted by the URL path) if it's morning where the user is.

Events are the notification of a detectable condition in a computer system. The detectable condition will typically be seen as a state change.

These are three required parts of event detection and notification:

• A change of state
• A process notices the state change
• The process sends a notification of the state change

Notifications are data transfers, not transfers of execution control. This is one of the hallmarks of evented systems that distinguishes them from other types of systems. Interrogatory-style systems use a request-response mode of interaction: “Will you do this?” Imperative-style systems use an RPC mode of interaction: “Do this!” In contrast, event interactions are declarative, stating only that a specific state change happened: “This happened”.

Because they are declarative, event notifications impose the semantics of what an event means on the processor rather than a generator. The event generator doesn’t know how a given processor will interpret the event. What’s more, it is not even required that an event processor take any action whatsoever. Each processor is free to interpret the event independently of other processors and generators in the system according to its context and particular purpose.

The event generator “raises an event”; in other words, it sends a notification that a state change occurred. The event processor “listens for” or “handles” these events.