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