W3C home > Mailing lists > Public > public-rif-wg@w3.org > July 2006

[RIFRAF] Proposal - new discriminators for RIFRAF

From: Paula-Lavinia Patranjan <paula.patranjan@ifi.lmu.de>
Date: Tue, 25 Jul 2006 09:00:10 +0200
Message-ID: <44C5C17A.4010803@ifi.lmu.de>
To: public-rif-wg@w3.org
Hi,

the analysis of the requirements we moved to RIFRAF during F2F3 and the 
discriminators of the current RIFRAF
http://lists.w3.org/Archives/Public/public-rif-wg/2006Jul/0027
has shown that events and actions, which are needed for production and 
Event-Condition-Action (ECA) rules, are not covered by the current 
RIFRAF. This email proposes such discriminators and hopes to start 
discussion on this for determining the ones that should be added to RIFRAF.

Regards,
Paula

-------------------------------------------------------------------------------------------------------------------
Proposal: Discriminators related to events and actions in reactive rules

This is a proposal made by REWERSE (Paula-Lavinia Patranjan and Michael 
Eckert)

A few comments on the proposal before starting with the discriminators:
We propose discriminators which are classified into categories (events, 
actions, conditions, general) but we need to find a suitable place for 
them in the RIFRAF structure when they are accepted by the group.
The discriminators are given in the form of questions so as to ease 
extending the RIFRAF questionnaire.
We start at a higher, more general level of discriminators and stepwise 
go into details.
The focus is here more on ECA rules, it would be good to check whether 
important issues for production rules are missing here.


Events
-------

1. Does the language offer support for programming reactive behaviour 
(automatically react to situations of interest)?
1.1 Yes
1.2 No

The following questions are for the case that 1 is answered positively:

2. Are the event specifications (which express classes of events to 
react to) implicit (conditions only on the state of the data, as is the 
case for production rules) or explicit (conditions on events changing 
the state, as is the case for ECA rules)?
2.1 Implicit
2.2 Explicit

3. Which is the conflict resolution used for rules (in case that the 
occurrence of an event triggers more than one rule)?
3.1 non-determinstic: all rules fire
3.2 non-deterministic: one rule fires
3.3 deterministic: priority-based selection of rules
3.4 other approach, namely ....

If 2.2 is chosen for the question 2:

4. Does the language support only atomic events or also composite events 
(combinations of more than one event such as temporal or sequence)?
4.1 Only atomic events
4.2 Both kinds of events

5. Can variables be used in event specifications (so as to select data 
from events that have occurred)?
5.1 Yes
5.2 No

6. Event specifications can also refer to events that have occurred in 
the past (i.e. before the event specification has been registered) or 
are they forward-looking?
6.1 Refer also to the past
6.2 Just forward-looking

7. Does the language support internal and/or external events (i.e. 
events that occur at remote nodes/entities)?
7.1 Just internal events
7.2 Internal and external events

8. Which is the approach to event consumption used in the language 
(consumption for a single rule)?
8.1 Events are consumed (events are used once in an event specification)
8.2 Events are not consumed (same event can be used to match different 
parts of an event specification)
8.3 Different modes are provided for event consumption so as to use the 
approach suitable for the chosen application


9. Which type of event specification is used in the language?
9.1 Algebraic
9.2 Linear temporal logic
9.3 Event calculus
9.4 Other approach, namely ...


Conditions
------------

1. Does the language support conditions on variables that occur in event 
specifications?
1.1 Yes
1.2 No

2. It is possible to express conditions on the state before/after the 
change?
2.1 Just after the change
2.2 Before and after the change


Actions
--------

1. Which types of actions are supported (multiple choices possible here)?
1.1 updates to data
1.2 updates to rule base (e.g activating or deactivating rules. 
inserting or deleting rules)
1.3 raising and sending events
1.4 procedural attachements
1.5 control of transactions (e.g commit, abort)


2. Does the language support internal and/or external actions (e.g 
raising and sending events to external entities)?
2.1 Just internal actions
2.2 Internal and external actions


3. Does the language support the execution of complex actions  (such as 
sequences of updates on data) specified in a rule?
3.1 Yes
3.2 No

4. Can variables used in the condition part/condition and event part 
also be used in the action part of a rule?
4.1 Yes
4.2 No



General
---------

1. Is language coherency one of the design principles followed during 
the language's development (meaning that same paradigms are used for all 
components of a rule, same language for all components of a rule)?
1.1 Yes (homogenity)
1.2 No (heterogenity, e.g. Event part specified in Snoop, Condition part 
in XQuery, and Action part in XUpdate for an ECA rule)

2. Are the different parts of a rule (e.g. Event, Condition, Action 
parts for a ECA rule) clearly separated (separation of concerns)?
2.1 Yes
2.2 No








Received on Tuesday, 25 July 2006 07:00:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:30 GMT