- From: Gerd Wagner <wagnerg@tu-cottbus.de>
- Date: Wed, 3 May 2006 22:14:40 +0200
- To: "'Vincent, Paul D'" <PaulVincent@fairisaac.com>, "'Alex Kozlenkov'" <alex.kozlenkov@betfair.com>, "'Dave Reynolds'" <der@hplb.hpl.hp.com>
- Cc: <public-rif-wg@w3.org>
> Alex: just some views on ECA from a vendor in this space... Paul, you mean from a production rule vendor's point of view, right :-? > > various events, not just data changed. > > [PV>] Note that this is (mostly) an execution aspect. If I have an ECA > rule that occurs on event A, it looks very similar to a PRule with a > condition of the type "event A occurred". I guess, ECA rule vendors would not agree with your attempt to neglect the specific semantics of events. It's not an execution aspect, it's a question of the right semantics. Normally, "condition" (in the sense of "logical condition") means "state condition", where "state" may refer to the state of a system, or to the "state of affairs". Now, an event corresponds to a state change and is therefore a completely different kind of thing that cannot be subsumed under the concept of a state condition. A complex logical condition formula is formed with the help of logical connectives, while a complex event expression is formed with the help of a different set of (event composition) operators. It's true that logical conditions and events are all mixed up in production rules. Semantically, this is a mess (and typically production rules do not have much support for event composition). But you may consider it a strength, making production rules a versatile programming paradigm (however, without a clear formal semantics). -Gerd
Received on Wednesday, 3 May 2006 20:14:31 UTC