JSON Rules is a declarative rule language for the World Wide Web. It has been created to satisfy at least the following list of requirements: (1) create and execute rules in browser; (2) support for ECA and PR rules; (3) the Working Memory contains event-facts. Here we extend the language with the concept of built-ins (predicates and actions). We focus on the relation with RIF-DTB, however with a strong emphasis on the environment where the rules are going to be executed: the web browser. As such we introduce here an initial set of built-ins, as well as the architectural aspects that should be taken into consideration for an engine implementing the JSON Rules language.
There is a multitude of rule languages out there (i.e. Drools [
JSON Rules introduced initially in [
rules execution is the update of the WM i.e. the DOM of the page. Therefore, the language design is tailored to the environment where rules are going to be executed.
With respect to its condition language, JSON Rules was in uenced in its
syntax by other rule languages such as Drools [
Any JSON Rule is identi ed by an id. A rule may have a priority - if this attribute is missing then its implicit value is 1. The rule engine executes the rules in a down counting order (from greater priority to lower priority). However, the execution order for rules with the same priority is irrelevant. One signi cant property of a JSON Rule is the appliesTo property. This property stores an array of URLs to which this rule refers to i.e. a list of URLs de ning the context in which this rule can be applied. Based on this property, rules are grouped in rule sets.
An EventExpression is an expression capturing any DOM Event [9]. Therefore, it has a type, target, timeStamp and phase properties, each of them allowing a JSONTerm as a value. Inside the rule engine, EventExpression is matched with DOM Events at their occurrence (we allow only atomic events with no duration i.e. the events are consumed immediately when they occur) time. Consuming events yields into event-facts creation in the WM and such facts are immediately consumed. The engine itself is event-based i.e. all internal processes and activities are event-driven. This is imposed by the environment where the engine runs - the Web browser. Generally, the engine consumes events, through its Working Memory, check conditions and execute actions.
A JSON Rule may contain a list of conditions, logically interpreted as a
conjunction of atoms. The language provides the following types of atoms:
Description, JavaScriptBooleanExpression, XPathCondition, NodeEquality
and Negation. The Description conditional is similar to Drools [
The XPathCondition is used to test that a DOM Node is found in the list of nodes returned by evaluating an XPath expression. The last two NodeEquality and Negation are pretty much obvious. They are used to test equality between two terms, respectively to negate a conditional atom.
As usual, a rule has associated a list of actions that have to be performed, if the rule conditions hold. An action is a call to any available JavaScript function. Actions are executed sequentially. The reader may notice that such kind of actions can determine also side e ects i.e. more than simple updates on the Working Memory (communication with a server that has no e ect on the WM).
As stated above since it is almost mandatory for any rule language to provide means of translation to and from RIF this paper makes the rst steps towards translation from RIF to JSON Rules and vice versa by tackling the problem of built-ins. 2
This section deals with built-ins for the JSON Rules language, along with the
architectural and technical aspects imposed by the context (web browsers) and
the programming language (JavaScript, ECMAScript [10]) in which the JSON
Rules [
Built-in means constructed as a non-detachable part of a larger structure. In case of rule systems built-ins encapsulate commonly used functionality, provided as predicates or functions. Built-ins also help in maintaining the clean declarative design of rules.
As described in the Conclusion of RIF-UCR [11] "the goal of the RIF working group is to provide representational interchange formats for processes based on the use of rules and rule-based systems. These formats act as "interlingua" to interchange rules and integrate with other languages, in particular (Semantic) Web mark-up languages."
JSON Rules foresees compliance with Rule Interchange Format (RIF)2. As such the JSON Rules aims to provide the built-ins de ned in RIF-DTB [12], beside others that refer to the mashup context. 2.1
RIF-DTB [12] is the reference document concerning built-in datatypes, predicates, functions supposed to be supported by RIF dialects such as: RIF Core Dialect [13], RIF Basic Logic Dialect [14] and RIF Production Rules Dialect [8]. According to RIF-DTB document each dialect takes use of a superset or a subset of datatypes, predicates or functions de ned in RIF-DTB. The datatypes taken into account by the RIF-DTB [12] are imported either from W3C XML Schema De nition Language (XSD) [15] or from rdf:PlainLiteral: A Datatype for RDF Plain Literals [16]. Predicates or functions have been ported from XQuery 1.0 and XPath 2.0 Functions and Operators [17] or from rdf:PlainLiteral: A Datatype for RDF Plain Literals [16].
The list of predicates and function built-ins taken into consideration by RIFDTB comprises among others: predicates for literal comparison, numeric functions and predicates, function and predicates on boolean values, on string, on date/time and duration, on XMLLiterals, on rdf:PlainLiteral. 2.2
The general technical guide line that governs the architectural aspects and any other aspects is the compliance and conformity with the ECMAScript standard [10].
Beside the built-ins (predicates and functions) classi cation introduced in
RIF-DTB [12] that span all the RIF dialects, we introduce here a set of built-in
actions that serve a di erent purpose, mainly actions needed in dealing with
mashups. As introduced in [
Although we are not going to address here the problem of translating RIF constants' names, symbols, or namespaces, minimal introduction of ECMAScript concepts are necessary.
One of the most important concept is the closure concept. The ECMAScript [10] standard explains a closure as a "function with some arguments already bound to values". Others de ne a closure3 as "an expression (typically a function) that can have free variables together with an environment that binds those variables (that "closes" the expression)".
As stated in [18] "JavaScript's extreme dynamism equips it with tremendous exibility, and one of the most interesting yet least understood facets of its dynamism involves context".
On top of these two concepts (closure, context ) the concept of namespace is de ned. We understand by the notion of namespace hierarchies of nested objects as de ned also in [18].
Another characteristic of JavaScript is that it is weakly typed. 2.3
There are a couple of general guidelines that should be taken into account when de ning functions and predicates, either user de ned or built-in:(1) in order to avoid name clashing in JavaScript global context it is recommended to use proper namespaces; (2) predicates should always return a default value, undefined value should be avoided.
To simplify the process of creating namespaces JavaScript libraries such as Dojo4 could be used.
Because the function word is reserved in JavaScript its usage should be avoided in a di erent context other than de ning a JavaScript function.
Another important issue that must be taken into account is that the JavaScript code for a page runs in a common context, and as such any rede nition of the same object will override the initial implementation. 2.4
This section explains how RIF built-in datatypes, predicates and functions are translated into JSON Rules, respectively JavaScript.
In order to preserve the semantics type mapping is necessary. Table 1 de nes the mapping between RIF built-in datatypes and JavaScript datatypes. E4X [19] datatype is also taken into account. Since JavaScript is weakly typed in most
RIF datatype xs:string xs:normalizedString xs:token xs:language xs:Name xs:NCName xs:ID xs:IDREF xs:NMTOKEN xs:ENTITY xs:NOTATION xs:anyURI xs:hexBinary xs:base64Binary xs: oat xs:double xs:duration xs:integer xs:negativeInteger xs:long xs:int xs:short xs:byte xs:nonPositiveInteger Number, cust. type of the cases a custom type must be built. In Table 1 this is emphasized by the cust. type notation. The same table speci es for each custom type, the base JavaScript type or types on which the custom type must be based. As previously stated datatypes as well as functions and predicates must be grouped by means of proper namespaces. In the RIF-DTB case datatypes are identi ed by the following namespace: http://www.w3.org/2001/XMLSchema#. As convention this gets translated into org.w3c.xs. For example the xs:duration datatype is identi ed with: http://www.w3.org/2001/XMLSchema#duration. This one gets translated into org.w3c.xs.Duration. The namespace for RDF datatypes is org.w3c.rdf.
In a similar way the namespaces for the RIF predicates and functions are: org.w3c.rif.pred and respectively org.w3c.rif.func.
JavaScript datatype String String, cust. type String, cust. type String, cust. type String, cust. type String, cust. type String, cust. type String, cust. type String, cust. type String, cust. type String, cust. type String, cust. type Array, cust. type Array, cust. type Number, cust. type Number String+Date, type Number, cust. type Number, cust. type Number, cust. type Number, cust. type Number, cust. type Number, cust. type
RIF datatype JavaScript
datatype xs:nonNegativeInteger Number, cust. type xs:unsignedLong Number, cust. type xs:unsignedInt Number, cust. type xs:unsignedShort Number, cust. type xs:unsignedByte Number, cust. type xs:positiveInteger Number, cust. type xs:decimal Number, cust. type xs:boolean Boolean xs:dateTime Date xs:date Date, cust. type xs:time Date, cust. type xs:gYearMonth Date, cust. type xs:gMonthDay Date, cust. type xs:gYear Date, cust. type xs:gDay Date, cust. type xs:gMonth Date, cust. type cust. xs:NMTOKENS String+Array, cust.
type xs:IDREFS String+Array, cust.
type xs:ENTITIES String+Array, cust.
type xs:QName String, cust. type xs:anyType E4X XML object rdf:PlainLiteral String rdf:XMLLiteral E4X XML object
The implementation for custom datatypes is inspired from J2EE implementation (i.e. javax.xml.datatype.Duration). The Duration custom type provides the following list of methods: add(org.w3c.xs.Duration rhs); addTo(Date date); compare(org.w3c.xs.Duration duration); getDays(); getHours(); getMinutes(); getMonths(); getSeconds(); getSign(); getYears(); isLongerThan(org.w3c.xs.Duration duration); isShorterThan(org.w3c.xs.Duration duration); negate().
In the RIF-DTB context built-in predicates and functions are de ned with the following artifacts: (1) name of the built-in; (2) external schema of the builtin (the signature of the built-in); (3) for a RIF built-in function - how it maps its arguments into a result - in RIF terms this means the mapping of Iexternal( ) in the formal semantics of [20] and [14]; (4) for a RIF built-in predicate - how it gives the truth value when arguments are substituted with values from the domain - this corresponds to the mapping Itruth Iexternal( ) in the formal semantics of [20] and [14]; (5) the domains for the built-ins' arguments.
RIF-DTB explains that "typically, built-in functions and predicates are dened over the value spaces of appropriate datatypes, i.e. the domains of the arguments. When an argument falls outside of its domain, it is understood as an error."
In RIF-DTB the predicate evaluating greater than is de ned as follows: name pred:numeric-greater-than schema (?arg1?arg2; pred : numeric greater than(?arg1?arg2)) domains xs:integer, xs:double, xs: oat, or xs:decimal for both arguments mapping When both a1 and a2 belong to their domains
Itruth Iexternal(?arg1?arg2; pred : numeric greater than(?arg1?arg2))(a1a2) = t if and only if op : numeric greater than(a1; a2) returns true, as de ned in [17], f otherwise. Also RIF-DTB speci es that "if an argument value is outside of its domain, the truth value of the function is left unspeci ed." The numeric-greater-than predicate could be implemented in JSON Rules as depicted in Example 1.
Since the hyphen based notation used by RIF in the predicates and function names can not be used in JavaScript the camel hump notation should be used instead. As such the name numeric-greater-than gets translated into numericGreaterThan.
The mapping of the signature is obvious, with respect to the list of arguments.
Based on Table 1 xs:integer, xs:double, xs:float, or xs:decimal RIFDTB datatypes are translated into custom types but based on the JavaScript number datatype.
With respect to RIF note that if the type of any of the arguments is outside of the speci ed domain then no result should be given. This situation can be dealt at least in three ways: (1) the value returned could be the JavaScript special value undefined; (2) JavaScript isNaN() function could be used and in case of true the Number.NaN should be returned; (3) an exception could be raised.
However since the RIF speci cation states that this predicate should behave as de ned in [17], in case of a NaN value, false is returned. As such this approach can not be used here. In other cases any of the three approaches could be used. Example 1 (De ning a built-in predicate). org=new function(){}; org.w3c=new function(){}; org.w3c.rif=new function(){}; org.w3c.rif.pred=new function(){}; org.w3c.rif.pred.numericGreaterThan=function(arg1,arg2) { try{ if (isNaN(arg1) || isNaN(arg2))
return false; if (arg1>arg2) return true; else
return false; }catch(e){ //log error //console.log(e); i.e. if Firebug is used } } return false;
This approach could be used in general to map all RIF built-in predicates and functions.
In addition the approach could be used to de ne libraries of actions oriented towards usage of well known services such Twitter5, Facebook6, Youtube7 and so forth through their APIs. 2.5
In mashups case there could be identi ed a set of operations that happen regularly, such as loading of services, memory cleaning etc. These type of functionality is provided under the org.jsonrules.builtin.mashups.system namespace. Functionality such as load or memoryCleanUp is provided as built-in functions the named namespace.
The existence of services is a prerequisite for the mashups, and as such they have to be available for the mashup, when this is instantiated.
Recall that we have in mind mashups modeled with JSON Rules that run in
the browser [
However rstly they need to be made available to the choreographer. The browser loads the content of the choreographer and a DOM Basic Event load it is raised. These functions should be used in general in relation with a load event, because its main purpose is to make available for the choreographer the necessary services.
The term services here has a broader understanding and comprises at least the following: web page, RPC service, AJAX object.
The signature of org.jsonrules.builtins.mashups.load function is: org.jsonrules.builtins.mashups.load($what,$where). In RIF-DTB terminology the signature of a function is the schema of a function.
The $what argument refers to what needs to be loaded. this could be an URI (Uniform Resource Identi er) or it could be a reference to an AJAX object.
$where argument refers to the place where the service or the response of an AJAX request will be stored. This could be for example an iframe, a div, both of them identi ed by an id, a reference to a JavaScript object. 3
This paper touched the problem of built-ins for JSON Rules in relation with RIF. This is a step towards translation JSON Rules to and from RIF. RIF builtin datatypes, predicates and functions have been taken into consideration, as well as other type of built-ins that in principal are useful in the mashups context. To maintain similar behavior functionality grouped, namespaces have been suggested for RIF-DTB and mashups environments. Beside all these technical aspects necessary for built-ins de nition in the context of JSON Rules has been taken into account. 7. OMG: Production Rule Representation (PRR), Beta 1. Technical report, OMG (November 2007) 8. de Sainte Marie, C., Paschke, A., Hallmark, G.: RIF Production Rule Dialect.
W3C Working Draft (July 2009) http://www.w3.org/TR/rif-prd/. 9. Hohrmann, B., Hegaret, P.L., Pixley, T.: Document Object Model (DOM) Level 3 Events. Technical report, W3C (December 2007) 10. ECMA: ECMAScript Language Speci cation. http://www.ecmainternational.org/publications/ les/ECMA-ST/Ecma-262.pdf (December 1999) 11. Paschke, A., Hirtle, D., Ginsberg, A., Patranjan, P.L., McCabe, F.: RIF Use Cases and Requirements. W3C Working Draft (December 2008) http://www.w3.org/ TR/rif-ucr/. 12. Polleres, A., Boley, H., Kifer, M.: RIF Datatypes and Built-Ins 1.0. W3C Working
Draft (July 2009) http://www.w3.org/TR/rif-dtb/. 13. Boley, H., Hallmark, G., Kifer, M., Paschke, A., Polleres, A., Reynolds, D.: RIF
Core Dialect. W3C Working Draft (July 2009) http://www.w3.org/TR/rif-core/. 14. Boley, H., Kifer, M.: RIF Basic Logic Dialect. W3C Working Draft (July 2009) http://www.w3.org/TR/rif-bld/. 15. Peterson, D., Gao, S.S., Malhotra, A., Sperberg-McQueen, C.M., Thompson, H.S., Biron, P.V.: W3C XML Schema De nition Language (XSD) 1.1 Part 2: Datatypes. W3C Candidate Recommendation (April 2009) http://www.w3.org/ TR/2009/CR-xmlschema11-2-20090430/. 16. Bao, J., Hawke, S., Motik, B., Patel-Schneider, P.F., Polleres, A.: rdf:PlainLiteral: A Datatype for RDF Plain Literals. W3C Candidate Recommendation (June 2009) http://www.w3.org/TR/rdf-plain-literal/. 17. Malhotra, A., Melton, J., Walsh, N.: XQuery 1.0 and XPath 2.0 Functions and Operators. W3C Recommendation (January 2007) http://www.w3.org/TR/ xpath-functions/. 18. Russell, M.A.: Dojo The De nitive Guide. O'REILLY (2008) 19. ECMA: ECMAScript for XML (E4X) Speci cation. http://www.ecmainternational.org/publications/ les/ECMA-ST/Ecma-357.pdf (December 2005) 20. Boley, H., Kifer, M.: RIF Framework for Logic Dialects. W3C Working Draft (July 2009) http://www.w3.org/TR/rif-fld/.