<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Michael Neale wrote:
<blockquote
cite="mid:96ab3ced0711272106jda49900j85faebd03e777c69@mail.gmail.com"
type="cite">Hi Edson.<br>
<br>
My $0.02 AUD: <br>
<br>
1. I choose time-window( 30 min )<br>
</blockquote>
we have two different types of windows - time and length. The above
means each window would be a fixed separate keyword. Where as "win" and
then a sub-unit would would indicate the type of window. "-" does not
really indicate a sub unit, where as : and . do.<br>
<blockquote
cite="mid:96ab3ced0711272106jda49900j85faebd03e777c69@mail.gmail.com"
type="cite">2. I choose option 2: eg TemperatureReading(
window-events(60), window:time(1 min), temp > 50 ) from streamB<br>
</blockquote>
I think it would be a mistake to mix keywords and field constraints so
freely in an almost similar syntax. I think there needs to be a clearer
distinction between what is a behaviour attribute on a pattern and what
is a field constraint. behaviour attributes work on sets/groups of
objects, field constraints work on individual objects.<br>
<blockquote
cite="mid:96ab3ced0711272106jda49900j85faebd03e777c69@mail.gmail.com"
type="cite">3. I choose distinct Address() from $person.address
<br>
(I guess lexically speaking, its similar to exists, not, etc).<br>
</blockquote>
We didn't want ot make distinct a keyword, as their may be other user
implementations. For this reasn we wanted it to be a text glob the
parser can suck in and the factory creates the required implementation.
This is part of the reason for the need for delimeters, this extra
pluggabiilty/flexability ofcourse has a cost in removing the english
like qualities.<br>
<br>
The other option is we have a fxed and non user-extensible grammar, we
are still not sure on the likelyhood for the on alternatives to
distinct - although I can think of one other "last". In banking if you
have a stream of data come in you want the last entry for a given
ticker type. So distinct,last etc are simply ways to massage groups of
values for that window.<br>
<blockquote
cite="mid:96ab3ced0711272106jda49900j85faebd03e777c69@mail.gmail.com"
type="cite"><br>
<div class="gmail_quote">On Nov 28, 2007 12:08 PM, Edson Tirelli <<a
moz-do-not-send="true" href="mailto:tirelli@post.com">tirelli@post.com</a>>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Resending...<br>
<br>
---------- Forwarded message ----------<br>
<span class="gmail_quote"></span><br>
Karen and Matthias,<br>
<br>
Thanks for the suggestions. A few items that we need to solve before
we decide on a syntax:
<br>
<br>
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 t mulhe "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:
<br>
<br>
window:time( 30 min ) or time-window( 30 min ) or another variation of
that<br>
window:events( 60 ) or events-window( 60 ) or another variation of that<br>
<br>
2. The smallest "unit" in a rule definition is a Pattern, and right
now, a Pattern looks like this:
<br>
<br>
[<var-bind> : ] <Pattern-Type>( [<constraints>] )
[from <source>]<br>
<br>
<> : means must be replaced by the corresponding data<br>
[] : means optional <br>
<br>
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. <br>
So, thinking about a single pattern, how would you define a window for
it?<br>
<br>
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).<br>
<br>
option 1: [<var-bind> : ] <Pattern-Type>(
[<window-constraints> ,] [<constraints>] ) [from
<source>]
<br>
option 2: [<var-bind> : ] <Pattern-Type>(
[<constraints>] ) [from <source>] [with
<window-constraints>]<br>
<br>
Note: replace the "with" above with the keyword we chose.<br>
<br>
Just as a real world example, if you look at ESPER queries, they do
events correlation like this:
<br>
<br>
<pre>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</pre>
<br>
One example of event aggregation is this:<br>
<br>
<pre>select min(latencyAC) as minLatencyAC, max(latencyAC) as maxLatencyAC, avg(latencyAC) as avgLatencyAC
from CombinedEvent.win:time
(30 minutes)</pre>
<br>
So, you see that the time windows are defined for each pattern and they
may be different among joined patterns.<br>
Accumulate may have multiple inner patterns, and so, we need to be able
to define windows for each one.
<br>
<br>
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 []:
<br>
<br>
TemperatureReading( window:time(30 sec), temp > 50 ) from streamA<br>
TemperatureReading( window:events(60), window:time(1 min), temp > 50
) from streamB<br>
<br>
Something closer to what you suggested would be (replace "with" with a
chosen keyword) :
<br>
<br>
TemperatureReading( temp > 50 ) from streamB with window:events(60),
window:time(1 min)<br>
<br>
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.<br>
<br>
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:
<br>
<br>
Person( distinct address )<br>
<br>
we need to say something like:<br>
<br>
distinct Address() from $person.address<br>
Address( distinct ) from $person.address<br>
<br>
Anyway, item #3 is of minor importance right now.<br>
<br>
Sorry for the long e-mail.<br>
<br>
Edson<br>
<br>
<div><span class="gmail_quote">2007/11/27, <a
moz-do-not-send="true" href="mailto:kw14@mail.inf.tu-dresden.de"
target="_blank">
kw14@mail.inf.tu-dresden.de
</a> <<a moz-do-not-send="true"
href="mailto:kw14@mail.inf.tu-dresden.de" target="_blank">kw14@mail.inf.tu-dresden.de</a>>:</span>
<div><span>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi
Mark, hi Edson,<br>
<br>
in the following you'll find our suggestions regarding Drools syntax<br>
extensions for definition of windows and other node restrictions.<br>
<br>
Edson showed us an example of what you had in mind:
<br>
Number( avg : doubleValue ) from accumulate( TemperatureReading( [<br>
window:events( 30 ), window:time( 60 sec ), distinct ], $temp :<br>
temperature ), average( $temp ) )<br>
<br>
It calculates the average of distinct temperature readings in 60
seconds
<br>
or over 30 events (whatever comes first).<br>
<br>
Your notation has the advantage of being short, easy to use and
orthogonal<br>
to the current grammar.<br>
<br>
In contrast to the definition using square brackets, we'd prefer a more
<br>
explicit way of defining windows and other constraints. This increases<br>
readability and makes it easier for novices to define rules. You've also<br>
used a similar notation in your talk at Synasc 2007.<br>
<br>
So our version would look like this:
<br>
<br>
Number( avg : doubleValue ) from accumulate within|in|over 60s or 30<br>
events( distinct TemperatureReading($temp : temperature ), average(
$temp<br>
))<br>
<br>
It allows using nested 'accumulates' while its clear to which
'accumulate'
<br>
a window definition belongs. The usage of "in", "within" or "over" as a<br>
keyword is up to your preference. The "distinct" keyword could be used
in<br>
front of either an object or an attribute definition similar to select
<br>
"distinct *" vs. "select distinct fieldname" in SQL. We think it's
clearer<br>
to have it in front of the object/attribute it refers to.<br>
For collect, a definition would look similar:<br>
<br>
e.g
.<br>
ArrayList( ) from collect over 60s ( TemperatureReading( orderBy<br>
temperature > 0 , distinct id!=null ) )<br>
<br>
In this case, we also used an "orderBy" keyword similar to distinct.<br>
However, it could also be used like a function as is currently done
with
<br>
aggregation functions in 'accumulate':<br>
<br>
ArrayList( ) from collect over 60s ( TemperatureReading(
$temp:temperature<br>
> 0 , distinct id!=null ), orderBy($temp) )<br>
<br>
For us, orderBy and groupBy only make sense with the set operator
<br>
'collect'. Although, they could be used in 'accumulate', if the order of<br>
values is relevant to the result of a user-defined aggregation function
or<br>
if different result sets are created based on a grouping attribute. Are
<br>
you planning to support this?<br>
<br>
Window definitions can also make sense for the 'exists' and 'not'<br>
operators or a complete rule as already suggested by Edson.<br>
<br>
An alternative way of describing the windows and other constructs would
be
<br>
the one below. However, it would require additional brackets to show the<br>
scope of windows for nested accumulates and was therefore excluded from<br>
our considerations.<br>
<br>
Number( avg : doubleValue ) from accumulate( distinct
<br>
TemperatureReading($temp : temperature ), average( $temp ) ) over 60s or<br>
30 events<br>
<br>
Okay, we are aware that these suggestions would require more extensions
in<br>
the Drools grammar, but we believe the resulting rules are easier to
<br>
understand than the ones using the square brackets. So, that's open for<br>
discussion. :)<br>
<br>
Cheers, Karen<br>
<br>
<br>
<br>
<br>
</blockquote>
</span></div>
</div>
<span><br>
<br clear="all">
<br>
-- <br>
Edson Tirelli
<br>
JBoss Drools Core Development
<br>
Office: +55 11 3529-6000<br>
Mobile: +55 11 9287-5646<br>
JBoss, a division of Red Hat @ <a moz-do-not-send="true"
href="http://www.jboss.com" target="_blank">www.jboss.com</a>
</span><br clear="all">
<font color="#888888"><br>
-- <br>
Edson Tirelli<br>
JBoss Drools Core Development<br>
Office: +55 11 3529-6000<br>
Mobile: +55 11 9287-5646<br>
JBoss, a division of Red Hat @ <a moz-do-not-send="true"
href="http://www.jboss.com" target="_blank">
www.jboss.com
</a></font><br>
_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Michael D Neale<br>
home: <a moz-do-not-send="true" href="http://www.michaelneale.net">www.michaelneale.net</a><br>
blog: <a moz-do-not-send="true" href="http://michaelneale.blogspot.com">
michaelneale.blogspot.com</a>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>