This paper presents a JSON based rule language and its JavaScript-based rule engine towards providing Web 2.0 applications with rule-based inference capabilities. For interoperability purposes the Rule Interchange Format is used. While the rule engine is enough general, its main purpose is to execute production rules and Event-ConditionAction rules related to the web page DOM processing. This way the user's browsing experience will be enriched with the ability to modify on the fly the DOM of the current document as well as the browser user interface (Firefox).
for data that is going to be transmitted over network. While the rule engine is enough general, its main purpose is to execute production rules and EventCondition-Action rules related to the web page Document Object Model (DOM) processing. This way the user’s browsing experience will be enriched with the ability to modify on the fly the DOM of the current document as well as the browser user interface (Firefox). 2
While the ideas of RIAs are not new (see [
The most advanced work seems to be in [
JSON notation combined with JavaScript function calls offers large capabilities to express various kinds of rules. Recall that we deal both with production rules and with Event-Condition-Action (ECA) rules i.e. rules of the form Rule ID: ON EventExpression IF C1 && ... && Cn DO [A1, ..., Am] where the event part is optional and denotes an event expression matching the triggering events of the rule; C1, ... Cn are boolean conditions using a Drools like syntax and [A1, ... Am] is a sequence of actions.
The metamodel of a JSON Rule is depicted in Figure 1.
Example 1 (Production Rule).
For all elements of class ’note’ having as first child a ’ul’ change the first child background color to blue. Expressed in a logical form the above example looks like: ∀x∃y(Element(x) ∧ x.class =0 note0 ∧ y = x.f irstChild ∧ y.nodeN ame =0 ul0) → changeBackground(y,0 blue0) 2 http://www.p6r.com/articles/2008/05/22/an-xpath-enabled-rule-engine/ 3 http://archives.devshed.com/forums/compilers-129/ writing-a-rules-parser-in-actionscript-javascript-2370024.html
id : String priority : Integer = 1 appliesTo : URL conditions 0..*
1..* actions prr::Action {"id":"rule101", "appliesTo": ["http://www.example.org/JRules",
"http://www.google.com/"], "condition": "$X:Element( class==’note’,
$Y:firstChild) && ($Y.nodeName == ’ul’)", "actions":["changeBackground($Y, ’blue’)"] } The above example shows that a JSON rule is first of all, a JSON object. The appliesTo property states that the rule will apply only on the specific indicated pages (URLs).
The condition uses a Drools like syntax and state that all elements with the class attribute equals with note (i.e. $X:Element(class==’note’)) and with the first child an unsorted list (i.e. $Y.nodeName == ’ul’) must participate in the action.
The action changeBackground($X, ’blue’) should be an available userdefined function call. If no such function is available then no action is performed.
JSON Rules are also ECA Rules i.e. they are triggered by events (see Example 4). Below we provide descriptions of the rule constituents. 3.1
Condition A rule condition is always a conjunction of atoms. Empty conditions are interpreted as true conditions. As can be seen in the Figure 2, the language supports three kinds of atoms: JavaScriptBooleanCondition, Description and XPathCondition. The reader should notice that future extensions may involve other kinds of atoms.
* 1 binding
JavaScriptBooleanCondition This is the simplest conditional atom. Any JavaScript boolean expression is allowed. For example window.find(’rule’) or document.getElementById(’id’).value==10 are allowed.
Description This atom is related to the syntax of Drools pattern conditional. The metamodel of language descriptions is depicted in Figure 3.
A Description is bound to a JSONTerm, has a type and has a list of constraints. The type is one of the values described by DescriptionType enumeration. These values correspond to the node types defined in DOM Level 2 Core specification 4.
The Description offers two types of constraints PropertyRestriction and PropertyBinding.
– A PropertyRestriction (see Figure 3) describes a set of value restrictions to properties of the JSONTerm that are bound to it.
• The string property encodes a property name of a property belonging to the corresponding bounded JSONTerm. • operator is relational one. • The value is either a JSONTerm (Variable or DOM:Node), or a RegularExpression, or a String or a Number. – A PropertyBinding performs a variable binding of a property belonging to the related JSONTerm. After that this variable becomes available at the rule level (See example 1).
The condition below stands for all DOM entities of type Element that are text input elements with the value date of the form yyyy-mm-dd. Notice that for the value we used a regular expression that checks its format. Month can be only between 01-12. The regular value for day can not be greater than 31, and for month 02 the value for day can not be greater than 29. 4 http://www.w3.org/TR/DOM-Level-2-Core/idl-definitions.html type «enumeration»
DescriptionType +DOCUMENT_TYPE +PROCESSING_INSTRUCTION 1 +DOCUMENT +ELEMENT +ATTRIBUTE +TEXT +CDATA +COMMENT +FRAGMENT +NODE_LIST * 1
operator «enumeration» RelationalOperator +EQ +LE +LEQ +GE +GEQ JSONTerm binding
* DOM::Node *
Value
Constraint 1 1 *
* constraints PropertyBinding property : String
PropertyRestriction property : String javascript::Number
javascript::String javascript::RegularExpression XPathCondition The XPathCondition (see the metamodel in Figure 4) is the third type of conditional atom. This one compared with the other might be a little peculiar. For a usage example of this type of conditional we are going to use the example page below.
Example 3 (An XPath Condition). Consider the following page with the view depicted in Figure 5: <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head>
<title>XPathCondition</title> </head> <body> <div id="_div1" > <table border="1"> <tr> <td>T1:row 1, cell 1</td> <td>T1:row 1, cell 2</td> </tr> <tr> <td>T1:row 2, cell 1</td> <td>T1:row 2, cell 2</td> </tr> </table> </div> <div id="_div2"> <table border="1"> <tr> <td>T2:row 1, cell 1</td> <td>T2:row 1, cell2 </td> </tr> <tr> <td>T2:row 2, cell 1</td> <td>T2:row 2, cell 2</td> </tr> </table> </div> </body> </html>
Such a conditional can be bound to a JSONTerm (Figure 3. Recall that a JSONTerm is either a Variable or a DOM:Node.
Assuming that we want to change the background for all rows in all tables in the DOM of the current page, using the XPathCondition, the condition is: "$X in "html//table//tr" The variable $X has been used along with the reserved word in. The meaning is ”forall $X in the collection...” The evaluation of the xPathExpression returns a list of nodes ( In the previous example, the evaluation of the xPathExpression returns 4 nodes).
On the other hand, if we want to change the background only for a specific node by using an XPathCondition the condition is: {"nodeName":"tr", "firstChild":{"nodeName":"td", "textContent":"T2:row1, cell 1" } } in "html//table//tr" After evaluating the condition the background should be changed only for the first row of the second table (see Figure 5). 3.2
Actions
Our approach deals with standard actions of OMG Production Rule
Representation (PRR), [
PRR Standard Actions JSON Rules AssignExp change properties of an element InvokeExp any JavaScript function call AssertExp insert a DOM node RetractExp remove a DOM node UpdateExp update a DOM node
An invoke action is already provided in Example 1. It corresponds to a JavaScript function-call. The function must be available otherwise the action is ignored (not executed).
An assign action is usually intended to change the properties of an element. For example $X.setAttribute("value", "25") is an assign action changing the value attribute of an input element bounded to the variable $X. If $X is not bounded to an element allowing the attribute value then the engine will ignore such action.
An assert action is related to the creation of new nodes in the DOM e.g. is an assert action.
A retract action is the inverse of the assert action i.e. deletes a node from the DOM.
An update action is usually related to the content update of a DOM node. For example $X.replaceChild($Y,$Z) is an assert action.
* * eventTarget «enumeration»
DOM::EventType +LOAD = load +UNLOAD = unload +ONDBLCLK = ondblclick +...
type 0..1
The JSON event expression is related to the Event interface specification in DOM Level 2 Events5, therefore the properties of this expression have the same meaning as in the Event specification. At the runtime these properties of this expression are matched against the incoming DOM events and their values can be processed in the rule conditions and actions.
Example 4 (ECA Rule). {"id":"rule102", "appliesTo":["http://mail.yahoo.com/"], "eventExpression": { "eventType": "click",
"eventTarget": "$X" }, "condition":" ($X.nodeName == ’a’,
$X.href==’match(showMessage\?fid=Inbox)’)", "actions":["append($X.textContent)"] }
The rule from example 4 concerns the Yahoo mail and states that when click event is raised, if the event came from an a element, and if the href property matches the regular expression (rudimentary check that the link is an inbox Yahoo message link) then call append function with the message subject as parameter. 3.4
Additional parameters In addition to its main constituents a rule provides some other parameters: 5 http://www.w3.org/TR/DOM-Level-2-Events/ – The id is required and denotes the unique identifier of a rule. – The appliesTo property is required and holds a list of URLs on which the rule must apply e.g. the rule from Example 1 can be applied to the pages http://www.example.org/JRules and to http://www.google.com/. – Priority expresses the order of a rule in a ruleset. If no value is provided for it, default value is ”1”. Based on priorities the rule engine must execute the rules in a down counting order (from greater values to lower values). The execution order is not relevant for rules having the same priority. 4
The main characteristics of the rule engine are:
– Is a forward chaining rule engine using a modified RETE algorithm (see [
The component view of the engine is depicted in the Figure 7.
EventManager
InferenceEngine
RulesRepository Fig. 7. Rule Engine
WorkingMemory
A UML state diagram describing the functionality of the engine is depicted in the Figure 8.
When the InferenceEngine is started it loads the corresponding rules from the RuleRepository. After the rules are loaded, the EventManager gets active and it listens for events from the WorkingMemory. When it receives events from the WorkingMemory, the EventManager informs the InferenceEngine about it. The InferenceEngine computes rules to fire. If rules are found then it fires them, and the WorkingMemory is changed. When no rules are computed then it stops.
RuleRepository
RulesLoaded DeterminePossibleRulesToFire
InformOfEvents
Rule Loading EventManager Opposed to usual rule engines, that stop their activity when no rules can be fired, this stops only when the WorkingMemory exists no more. When rules can not be fired, but the WorkingMemory still exists, the engine gets into an idle state, and waits to be informed about new events from the EventManager. Is represented by the DOM of the current page. The WorkingMemory is special because it is event based, DOM is changed through events. Is the ”brain” of the system. Based on the facts (DOM) of the Working Memory and based on the current page corresponding ruleset, it performs the matching operation and executes rules. The event manager is a combination between JavaScript and the Working Memory - DOM of the current page. The Event Manager takes advantage of the fact that the DOM itself is event based. All changes and in general all DOM events are reported to the main document object. This is based on the bubbling effect of DOM events. Rules are stored in the repository. The repository can be local or remote. In both cases the storing language is JSON based as described in Section 3. 5
This paper describes an approach of enriching RIAs with rule-based reasoning.
JSON Rules provides the JavaScript engine with reasoning capabilities and the
users can write their own rules. The rules syntax is based on JSON notation,
therefore does not require high effort to accommodate it. Rules are simpler but
powerful, their main goal being to change the DOM of the page they apply. The
rule actions comply with the proposed OMG standard for production rules and
are enough general to achieve all kind of DOM changes as well as any kind of
side effects. The next immediate step will take into account the engine
interaction with both user defined events and XMLHTTPRequest events to increase
the power of the reaction rules to dynamically handle the page AJAX-based
interactions. On a medium term JSON Rules should deal with metadata (with
emphasis on RDF[