BRMS: Locking
by Darko IVANCAN
JBoss AS 4.0.5
JBoss Drools 4.0.3
JDK 1.5.13
Hi,
I'm evaluating JBoss Drools and wanted to check the locking capabilities
in the BRMS, to see it the BRMS can be used on a cluster, i.e. multiple
BRMSs one DB-Server.
So I started first on one single machine, just to check the locking
capabilities:
Started BRMS, logged in using FireFox and Logged in using Safari.
1) Open one (and the same) rule in both session
2) edit and save rule in one session
3) edit and save rule in another session
=> error
So, from what I see there is no locking mechanism in the BRMS.
As from what I see in JackRabbit, it does support transactions, but
locking seems to be needed in the BRMS itself, i.e. one layer above
JackRabbit.
My question, and maybe someone can answer/confirm these spending some of
his valuable minutes:
1) Is locking included or on the roadmap ?
2) Did I miss a configuration parameter to enable locking ?
3) How can stale-locks be cleaned ? Admin-only?
Thanks a lot for your valuable input and thanks for this great product,
Darko Ivancan
16 years, 5 months
Fwd: Window syntax extensions
by Edson Tirelli
Resending...
---------- Forwarded message ----------
Karen and Matthias,
Thanks for the suggestions. A few items that we need to solve before we
decide on a syntax:
1. The qualification of the units: we need to be able (as a CEP engine) to
allow the definition of arbitrary time windows, like seconds, minutes or
hours or compositions of them. So, a few notations could be used: 30 sec, 30
min, 30 hours (or variations of that), 25:10:23 (25 hours and 10 minutes and
23 seconds), etc. I would really like to avoid hard coding the unit parsing
in the DRL parser, since the parser is one of the more delicate pieces of
the code to change. We can avoid that if we use delimiters to declare the
"parameters" of the window, as the parser can simply read it all as a String
chunk and let each window handler deal with its own units. So, the
suggestion is to use () or something like that to provide the parameters to
the window handlers, in a way like that:
window:time( 30 min ) or time-window( 30 min ) or another variation of that
window:events( 60 ) or events-window( 60 ) or another variation of that
2. The smallest "unit" in a rule definition is a Pattern, and right now, a
Pattern looks like this:
[<var-bind> : ] <Pattern-Type>( [<constraints>] ) [from <source>]
<> : means must be replaced by the corresponding data
[] : means optional
Now, what we need is a way to declare window constraints for patterns. The
accumulate example I gave you was not a good one, because accumulates have 2
or more patterns (the inner patterns and the accumulate result pattern). You
can even apply different window constraints for each of the patterns.
So, thinking about a single pattern, how would you define a window for it?
Given the current grammar and the concept of pattern, I see only two
options: either we define the window constraints inside the pattern
declaration ( i.e., near regular constraints), or we create another keyword
to introduce them (like we have the "from" keyword).
option 1: [<var-bind> : ] <Pattern-Type>( [<window-constraints> ,]
[<constraints>] ) [from <source>]
option 2: [<var-bind> : ] <Pattern-Type>( [<constraints>] ) [from <source>]
[with <window-constraints>]
Note: replace the "with" above with the keyword we chose.
Just as a real world example, if you look at ESPER queries, they do events
correlation like this:
select *
from TxnEventA.win:time(30 minutes) A
join TxnEventC.win:time(60 minutes) C on A.transactionId =
C.transactionId
join TxnEventB.win:time(30 minutes) B on B.transactionId =
C.transactionId
where C.transactionId is null
One example of event aggregation is this:
select min(latencyAC) as minLatencyAC, max(latencyAC) as maxLatencyAC,
avg(latencyAC) as avgLatencyAC
from CombinedEvent.win:time
(30 minutes)
So, you see that the time windows are defined for each pattern and they may
be different among joined patterns.
Accumulate may have multiple inner patterns, and so, we need to be able to
define windows for each one.
On our initial suggestions, we would define the window constraints inside
the pattern, as this is a lot better to avoid grammar ambiguities. The use
of square brackets would help to avoid the need of creating new keywords,
but as long as we decide that it is worth to create at least one keyword
(like "window" for instance), we can avoid the []:
TemperatureReading( window:time(30 sec), temp > 50 ) from streamA
TemperatureReading( window:events(60), window:time(1 min), temp > 50 ) from
streamB
Something closer to what you suggested would be (replace "with" with a
chosen keyword) :
TemperatureReading( temp > 50 ) from streamB with window:events(60),
window:time(1 min)
My preference is to keep that inside the pattern, but would like to hear
from you (if the change proposed in item #1 is ok) and from Mark and
Michael.
3. Regarding "distinct", "group by" and "order by", we want to support that,
specially "distinct". From a syntax perspective, I would like to use a
similar solution as we chose for the windows, so that we can keep the
language easier to learn, but if it is best for clarity to use them like
"distinct PatternA(...)", I'm ok with that too. Unfortunately, we can't
allow distinct directly for attributes, as different from SQL, we need to
declare all the patterns that make a tuple. So, instead of saying something
like:
Person( distinct address )
we need to say something like:
distinct Address() from $person.address
Address( distinct ) from $person.address
Anyway, item #3 is of minor importance right now.
Sorry for the long e-mail.
Edson
2007/11/27, kw14(a)mail.inf.tu-dresden.de <kw14(a)mail.inf.tu-dresden.de>:
>
> Hi Mark, hi Edson,
>
> in the following you'll find our suggestions regarding Drools syntax
> extensions for definition of windows and other node restrictions.
>
> Edson showed us an example of what you had in mind:
> Number( avg : doubleValue ) from accumulate( TemperatureReading( [
> window:events( 30 ), window:time( 60 sec ), distinct ], $temp :
> temperature ), average( $temp ) )
>
> It calculates the average of distinct temperature readings in 60 seconds
> or over 30 events (whatever comes first).
>
> Your notation has the advantage of being short, easy to use and orthogonal
> to the current grammar.
>
> In contrast to the definition using square brackets, we'd prefer a more
> explicit way of defining windows and other constraints. This increases
> readability and makes it easier for novices to define rules. You've also
> used a similar notation in your talk at Synasc 2007.
>
> So our version would look like this:
>
> Number( avg : doubleValue ) from accumulate within|in|over 60s or 30
> events( distinct TemperatureReading($temp : temperature ), average( $temp
> ))
>
> It allows using nested 'accumulates' while its clear to which 'accumulate'
>
> a window definition belongs. The usage of "in", "within" or "over" as a
> keyword is up to your preference. The "distinct" keyword could be used in
> front of either an object or an attribute definition similar to select
> "distinct *" vs. "select distinct fieldname" in SQL. We think it's clearer
> to have it in front of the object/attribute it refers to.
> For collect, a definition would look similar:
>
> e.g .
> ArrayList( ) from collect over 60s ( TemperatureReading( orderBy
> temperature > 0 , distinct id!=null ) )
>
> In this case, we also used an "orderBy" keyword similar to distinct.
> However, it could also be used like a function as is currently done with
> aggregation functions in 'accumulate':
>
> ArrayList( ) from collect over 60s ( TemperatureReading( $temp:temperature
> > 0 , distinct id!=null ), orderBy($temp) )
>
> For us, orderBy and groupBy only make sense with the set operator
> 'collect'. Although, they could be used in 'accumulate', if the order of
> values is relevant to the result of a user-defined aggregation function or
> if different result sets are created based on a grouping attribute. Are
> you planning to support this?
>
> Window definitions can also make sense for the 'exists' and 'not'
> operators or a complete rule as already suggested by Edson.
>
> An alternative way of describing the windows and other constructs would be
>
> the one below. However, it would require additional brackets to show the
> scope of windows for nested accumulates and was therefore excluded from
> our considerations.
>
> Number( avg : doubleValue ) from accumulate( distinct
> TemperatureReading($temp : temperature ), average( $temp ) ) over 60s or
> 30 events
>
> Okay, we are aware that these suggestions would require more extensions in
> the Drools grammar, but we believe the resulting rules are easier to
> understand than the ones using the square brackets. So, that's open for
> discussion. :)
>
> Cheers, Karen
>
>
>
>
>
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
16 years, 5 months
modify keyword in java
by Mark Proctor
I was thinking about the modify keyword and how nice it would to have
that work from java dialect too. I think we might be able to hack this
with a simple scanner.
1) scan for the "modify ("......") {". We can balance text the first
opening and closing parenthesis.
2) take the contents of the "("......")" and assign it to X and do
modifyRetract( X ). if the contents starts with "new" we need to handle
that slightly differently, note no ModifyRetract is needed and we have
to assign the results to an anonymous variable.
3) scan for "=" then backtrack to find the field name (delimeted by the
first "{" or a ","
4) for each field = Y write it to X.setX to Y
5) then do modifyInsert( Y )
I could write a custom line scanner for this, but wondering if it could
actually be done more efficiently in antlr?
Any takers? :)
Mark
16 years, 5 months
How can I help with BRMSv2 Docs
by Paul Browne
Folks,
The screen shots of BRMSv2 look cool.
Was thinking (since most of my comments on them were to do with Help
Pages and docs) that I should offer to help out with the Documentation
side of things.
- Is the BRMS in trunk stable enough to check out / any major changes
expected to the screens?
- Does the BRMS section of the Drools Doc need updated (and if so ,
should I do it describing the screens as they are *now*).
- I'd suggested a 'Help' link and a welcome / splash screen. Are you
thinking of including them in this release? If so, what format would you
like me to provide the help text in.
Paul
16 years, 5 months
Repository Export/Import
by Darko IVANCAN
JBoss DRools 4.0.3
JBoss AS 4.0.5
JDK 1.5.13
Hi,
In the process of designing our infrastructure we're looking at how
DRools could be used with staging environments.
The easy part:
We have per environment one BRMS-Server and in the same environment some
other servers running the Rules-Application, which will get the LATEST
rules from the BRMS-Server, using polling and a JMX/JMS trigger.
The tricky part:
We had the idea of taking a "valid version" from one stage to another.
So we could either use rule packages (snapshots) or repository exports.
As I see no easy way of passing a package from one BRMS to another, the
export/import options seems a feasible option.
My issue here is now, that this does not seem to work:
a) It takes an incredible amount of time to upload an export.
b) It seems, that the import has no effect to the contents shown in the
BRMS, after the import.
We do not want to go with the RuleAgent, as the environments should
really be separated.
So my question:
Is there an easy way to migrate data from one BRMS to another, so it can
be used by the RuleAgents ?
The RuleAgents will use an URI to pick up the LATEST version.
The Web-Interface itself of the BRMS is not needed, just the URI-Source
for the Rule-Agents.
Any ideas, hints ?
Thanks,
Darko Ivancan
16 years, 5 months
Ruleflow ActionNodes
by Mark Proctor
Kris,
ActionNodeInstanceImpl is a stateless representation of a node in a
process, and the ActionNode it references is also stateless. So why do
you accesss it indirectly?
protected ActionNode getActionNode() {
return (ActionNode) getNode();
}
protected Node getNode() {
return this.processInstance.getRuleFlowProcess().getNode(
this.nodeId );
}
--------------------
private Map nodes;
final Long idLong = new Long( id );
Look at PrimitiveLongMap and how its used, means no ObjectWrappers and
uses up a lot less memory than HashMap - as well as being marginally
faster. It is meant for situations where you no the keys are issued
incrementally, we use a key recycling class PrimitiveLongStack to ensure
we don't end up with gaps.
--------------------
I have MVELAction working now in the build framework. I don't really
like actionNode.getAction() which returns an Object, the execution
implemtentation is encapsulated so just actoinNode.execute( wm ) should
be fine, which then delegates to the MVELAction.
public void testSimpleAction() throws Exception {
final Package pkg = new Package( "pkg1" );
ActionDescr actionDescr = new ActionDescr();
actionDescr.setText( "list.add( 'hello world' )" );
PackageBuilder pkgBuilder = new PackageBuilder( pkg );
final PackageBuilderConfiguration conf = pkgBuilder.getPackageBuilderConfiguration();
MVELDialect mvelDialect = ( MVELDialect ) pkgBuilder.getDialectRegistry().getDialect( "mvel" );
PackageBuildContext context = new PackageBuildContext();
context.init( conf, pkg, null, pkgBuilder.getDialectRegistry(), mvelDialect, null);
pkgBuilder.addPackageFromDrl( new StringReader("package pkg1;\nglobal java.util.List list;\n") );
ActionNodeImpl actionNode = new ActionNodeImpl();
final MVELActionBuilder builder = new MVELActionBuilder();
builder.build( context,
actionNode,
actionDescr );
final RuleBase ruleBase = RuleBaseFactory.newRuleBase();
ruleBase.addPackage( pkgBuilder.getPackage() );
final WorkingMemory wm = ruleBase.newStatefulSession();
List list = new ArrayList();
wm.setGlobal( "list", list );
((Action)actionNode.getAction()).execute( wm );
assertEquals("hello world", list.get(0) );
}
Mark
16 years, 5 months
CEP/ESP support: initial commit
by Edson Tirelli
All,
As some of you already know, I created a branch to develop the CEP/ESP
support as well as the temporal extension to the engine. You can check it
out from here:
http://anonsvn.labs.jboss.com/labs/jbossrules/branches/temporal_rete/
Parent JIRA task is:
http://jira.jboss.com/jira/browse/JBRULES-1331
Right now I'm working on:
http://jira.jboss.com/jira/browse/JBRULES-1332
Today I committed the first few bits to it (
http://fisheye.jboss.org/changelog/~author=tirelli/JBossRules/?cs=16677). It
is not much, but the parser is now capable of identifying and handling
"event" declarations in the form of:
import event a.b.c.MyEvent
import event x.y.z.*
The engine is also able to correctly identify events as we discussed in
the mail thread last week.
Next step I am working on is getting the engine to support a special
type of fact handle: EventFactHandle. This will require a bit of refactoring
to get some conf information up in the WorkingMemory or RuleBase class.
From now on, the development of the features related to that will
accelerate and I will try to keep as much discussions as possible here in
the list. So, if you are one of those that loves open source, is interested
in the CEP/ESP subject and/or temporal reasoning, and want to get involved,
this is a good time for you to join the crew as we set sail. :)
Happy Drooling,
[]s
Edson
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
16 years, 5 months
Predict rule firing watching partial matches
by Alfonso González
Hello
We have developed a behaviours data driven application: when rules change
data model, behaviour changes. Model is some kind of network. Each time
system know a new case, we copy some piece of the model in order to rules
modifies the copy, but not the model (model is protected from rules). But
not all cases will fire rules, so is not efficient to build all the copy
each time, when maybe there wont be rules going to fire. So the more
efficient way to build the copy is: step to step exploring diferent paths,
and being able to predict not succesfull paths and then cancel this not
succesfull path in advance. Supposed a rule will fire 4 steps next, so step
1, 2 and 3 partial macthes must be happen. So, for each new path, after
every step, I could wacth if new partial matches has happen, and if not, we
can cancel this path a go in depth with other path. So the question is: is
ther any way to listen partial matches being happens, and can I know number
of partial matches from each rule or from a group of rules?
Thank you in advance
Alfonso González
DYNAGENT SOFTWARE
16 years, 5 months
Re: Interval-based vs. Time-based semantics
by Edson Tirelli
Matthias,
I agree with you and I say interval-based semantics is a go. I also
agree on representing point-in-time events as events with 0 duration.
> Another question that bothers me is whether you also intend to support
> different "consumption modes" like 'recent', 'chronicle' or 'unrestricted'
> (see paragraph 4.4. in the paper I sent to you; i.e. page 11 + 12 of the
pdf).
> For our use case, 'recent' context is probably best suited - however at
> least 'unrestricted' should be supported too (e.g. in sliding windows,
> no events can be discarded). What do you think?
My understanding is that the unrestricted mode is the default operation
mode of the engine, and as such, we get it for free. My understanding is
also that you can constrain the matching patterns to "emulate" recent and
chronicle modes. So, my suggestions is we leave a more transparent support
to "recent" and "chronicle" modes to a second phase, i.e., as soon as we
have all the basics working in the engine.
Regarding the ability of the engine to work with non-javabean facts, it
depends on a feature that is in our "to do list": pluggable extractors. The
idea is that you can configure the engine to use different strategies to
obtain a value from a fact. Example:
Cheese( type == "stilton" )
The above pattern makes the engine to use an extractor to read the value
of "type" from the fact. As it is today, the engine uses a "hardcoded"
extractor that knows how to read that attribute value from a javabean. What
we need is to implement support in the engine to use a different extractor
configured (and eventually provided) by the user. So, if Cheese is a JMS
message, an XML element, an Ontology instance, or a CSV record in a file,
does not matter for the engine, as long as the extractor can "read" that
value and provide it to the engine.
So, not supported yet, but we need that too for our next major release.
[]s
Edson
2007/11/13, Groch, Matthias <matthias.groch(a)sap.com>:
>
> Looking at it, it seems quite feasible to implement the operators and
> time-windows necessaries to correlate events using this semantics. The only
> thing I still don't know is related to a very practical (in the sense that
> is opposed to theory) question:
>
> * A method call in a programming language is an "atomic", point-in-time,
> operation. So, inserting an event into the engine, is also a point-in-time
> operation. Interval-based semantics presumes that an event has a duration,
> and a duration is only available "after" an event has finished. So, since we
> need a synchronized clock to allow appropriate reasoning and time-window
> management in the engine, how do we implement support for that? Do you
> understand my question? We can't allow the engine clock to move backwards,
> and we will not be able to wait eternally for events that may never arrive,
> so how to we map one semantics into the other?
>
> Will need to support point-in-time semantics for simple/atomic
> events, and interval-based semantics only for complex events? What are your
> ideas about this?
>
> IMO, the easiest way to unify point- and interval-based
> representation would be to choose interval-based semantics, and
> then represent atomic events by means of an interval of duration 0, i.e.
> start and end time of the interval are equal. This way we would avoid having
> two different semantics, everything could be handled using intervals and the
> 13 relations defined by Allen.
> However, for representing primitive events point-based semantics and the
> three relations (<, >, =) are sufficient. Problems start when setting up
> relations between primitive and complex events. One solution would be to
> introduce another 5 relations between points and intervals (like it is done
> in the QA approach). However, for reasons of simplicity, I'd prefer to see
> the point as an interval of length 0 just for this relation, so we can use
> the relations definded on interval-based semantics.
>
> As pointed out by the QA guys, with interval-based semantics you can
> unambigiously definine qualitative relations. However, defining quantitative
> relations (i.e. durations) is not straight-forward. For instance, let's
> say yo wanna check whether one composite event e2 occurs within 2 minutes
> after a first one e1 occurred. There are several ways to it, to be precise 4
> (plus mixed solutions). You could compare either the start points of both
> composite events, or the end points, or the start point of e1 with the end
> point of e2, or the end point of e1 with the start point of e2 (or some mid
> point inside both of the intervals). All of the options might be meaningful
> (depending on the use case), so probably one should offer support for all of
> it. Nevertheless it probably makes sense to have a default implementation,
> which in our opinion is that you have a look at the end point of e1 and the
> start point of e2.
>
> For time-window management, in our opinion the most suitable
> interpretation is to only include (composite) events which have
> terminated within the given boundaries. I agree that including events
> already at the time they start is error-prone since there's no guarantee
> that they eventually terminate (and when). Including events only if start
> and end point are within the boundaries of the window bears the risk of
> "loosing" events starting in one window but ending in another one.
>
> Although it's a nice assumption arriving events to be in the right (i.e.
> chronicle) order, there should be a support for delayed events. There should
> be a short delay (e.g. 1 min) in which late events are still accepted and
> inserted at the right point. That also means that rules which have fired
> already might have to be cancelled and reexecuted according to the new
> arrival order. In other words, reacting to incoming events should occur
> immediately, however, if late events arrive, some reevaluation must be done
> (but only in a certain interval; in this example, the system state older
> than 1 minute is untouchable). In order not having to wait for events
> forever (which may be delayed), one should define an upper bound after which
> no more events are accepted or old old events can be discarded. ILOG JRules
> uses two qualifiers for that: ARRIVAL_DELAY and MATCHING_HORIZON (see
> http://www.ilog.com/products/jrules/documentation/jrules66/rsoptimize/rs_...).
> I think we could do it in a similar way.
>
> Another question that bothers me is whether you also intend to support
> different "consumption modes" like 'recent', 'chronicle' or
> 'unrestricted' (see paragraph 4.4. in the paper I sent to you; i.e. page
> 11 + 12 of the pdf). For our use case, 'recent' context is probably best
> suited - however at least 'unrestricted' should be supported too (e.g.
> in sliding windows, no events can be discarded). What do you think?
>
> One last question (which is completely unrelated to all above): In a
> listener within my sample application, I receive events as JMS messages
> (API: http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/Message.html)
> containing a name, a parent id, a timestamp and several additional (unknown)
> parameters. As far as know, Drools only supports Java classes relying on
> the JavaBean standard of getters and setters without any parameters. I got 2
> problems: First of all, the attributes and the corresponding values are
> saved in a map inside the JMS message. You access a certain field of a JMS
> message by specifying the field name as a parameter, e.g. myMessage.
> getStringProperty(java.lang.String name), something which apparently is
> not allowed in Drools (or is there a workaround?) The second problem is,
> that there could be different events which, besides the standard
> attributes, have different attributes. In other words, at compile time I
> don't know which attributes an event instance will have, which means I
> cannot write a simple standard 'mapping function'. So what I currently do is
> to "unwrap" the JMS message, extract all parameters and create a new myEvent
> object with well-defined getters and setters. This myEvent instance is then
> added to the working meory. When sending a reponse (which is another
> event) back to my publish-subscribe-system, I have to go the opposite way,
> i.e. wrapping all the information from a myEvent instance in a JMS
> message. What would be nice is to directly process JMS messages, without all
> the (un)wrapping. Is there a way to do that in Drools?
>
> Cheers,
>
> Matthias
>
>
> ------------------------------
> *From:* ed.tirelli(a)gmail.com [mailto:ed.tirelli@gmail.com] *On Behalf Of *Edson
> Tirelli
> *Sent:* Tuesday, November 13, 2007 1:21 AM
> *To:* Groch, Matthias
> *Cc:* Walzer, Karen; Mark Proctor
> *Subject:* Re: Interval-based vs. Time-based semantics
>
>
> Matthias,
>
> Interesting paper! I didn't know it before. I now understand the
> additional declarative power that the interval-based semantics add to the
> reasoning!
> Looking at it, it seems quite feasible to implement the operators and
> time-windows necessaries to correlate events using this semantics. The only
> thing I still don't know is related to a very practical (in the sense that
> is opposed to theory) question:
>
> * A method call in a programming language is an "atomic", point-in-time,
> operation. So, inserting an event into the engine, is also a point-in-time
> operation. Interval-based semantics presumes that an event has a duration,
> and a duration is only available "after" an event has finished. So, since we
> need a synchronized clock to allow appropriate reasoning and time-window
> management in the engine, how do we implement support for that? Do you
> understand my question? We can't allow the engine clock to move backwards,
> and we will not be able to wait eternally for events that may never arrive,
> so how to we map one semantics into the other?
>
> Will need to support point-in-time semantics for simple/atomic
> events, and interval-based semantics only for complex events? What are your
> ideas about this?
>
> Regards,
> Edson
>
> PS: what do you think about moving our conversation to the dev list? is
> there any problem for you, your thesis or your job if we get a wider
> audience?
>
> 2007/11/12, Groch, Matthias <matthias.groch(a)sap.com>:
> >
> > <<Unified Semantics for Event Correlation Over Time and Space in Hybrid
> > Network Environments.pdf>> Edson,
> >
> > I'm still thinking about how to represent time. In the attached paper,
> > there's a counter-example prooving that point-based semantics aren't
> > appropriate in all cases. You can find it in paragraph of 4.3, on page
> > 11 of the PDF (= page 375 of the original conference proceedings).
> > For this reason, I'm in favor of using interval-based semantics instead
> > of point-based semantics. Meanwhile, I stumpled across another approach
> > combining the aforementioned. It's called Qualitative Algebra (QA). Have
> > you ever heard of that? Meiri introduced it
> > ( http://citeseer.ist.psu.edu/715273.html), and it was extended by
> > Barber
> > (http://citeseer.ist.psu.edu/barber00reasoning.html). It's quite
> > interesting since we then could use point-based semantics for primitive
> > events and interval-based semantics for complex events, and still are
> > able to define relations between them. However, I have the feeling it's
> > not very well-examined yet; moreover it would introduce additional
> > relations and therefore make things too complex (interval-based
> > semantics already deal with 13 relations; but as pointed out, we
> > probably cannot get around it)...
> > What do you think?
> >
> > Matthias
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
16 years, 5 months
