[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Edson Tirelli commented on JBRULES-3514: ---------------------------------------- ===== FROM DAVIDE ===== Hi Edson, my quick 2 cents on this proposal Section 2: I like the idea of "defining" rather than just declaring datatypes and events. This problem actually overlaps much with "semantic" classes (actually semantic traits), where, in addition to declaring the type, ancestors and member fields, an "equivalentTo" LHS-like definition(s) may be provided. So I wonder if we could merge the two parts (syntax is tentative here) declare event VoiceCallEvent extends SuperTypeEvent // promote event to first-class ? into( voiceCalls ) // either keyword or annotation @into( voicecalls ) ? as // equivalent-to definitions callStart : CallStartEvent() -> callEnd : CallEndEvent( callingNumber == callStart.callingNumber ) $phone : MobileDevice( number == callStart.callingNumber ) $cust : Customer( id == $phone.customerId ) ; // fields. in DL would be considered anonymous superclasses callStart : CallStartEvent // ok: initialize when var name coincides callEnd : CallEndEvent customer : Customer = $cust // should we allow explicit initialization using other expressions, possibly involving local vars ? end Section 3 : ok Section 4 : I'd either use infix A() -> B() or prefix notation, but I wouldn't mix the two seq( A() B() ), as we do with and/or CEs. Unless the parser requires so :) Question: what about a "strict sequencing" operator A() => B(), meaning "B() after A() and nothing in between"? Question: what about the interval deadlines, like we have in "after[a,b]" ? Section 4 again :) : Another options, maybe uglier? A+( ... ), B*(....), C[2:4](...) Yet another, maybe more explicit? exists[+] A(), exists[*] B(), exists[2:3] C() Section 4.1 Ok! this is again related to what I've been dreaming of writing even in more traditional DRL: $x : exists X() Section 5.5 I'd use "not" ... what would be the high-level difference between "no" and "not" from a conceptual perspective? (not talking about implementation here) Moreover, shouldn't we stick to the "not X( this after $y )" semantics we already have? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Edson Tirelli commented on JBRULES-3514: ---------------------------------------- Davide, thanks for the feedback. Regarding your comments: h5. Section 2 I considered that as well, but I think it is best to keep them as 2 separate pieces of syntax. The easiest way to see this is that a "declare type" statement is like declaring a class, while an "event" statement is like instantiating that class. While there can be only one "declare type" for each type, there can be multiple "event" statements to instantiate events of the same type based on different criteria. Just a dumb example to illustrate the idea: {code}declare type AccountDebit @role( event ) accountId : String ammount : BidDecimal end event AccountDebit as ATMTransaction( type == TransactionType.Withdraw, accountId : accountId, ammount : totalAmmount ) end event AccountDebit as InternetTransaction( type == TransactionType.TransferOut, accountId : accountId, ammount : totalAmmount ) end {code} h5. Section 4 * I agree that we don't want both a delimiter and the infix -> CE, but I am still not sure the infix will be enough for our needs. Will have to proceed to the design and implementation and revisit this issue when we get there. * The "strict followed-by" (=>) operator remains a possible implementation, but the more I think about it, the less I think it will be used, because in most of the use cases, there aren't any assurances that the events won't be intermixed in the streams coming into the system. Unless we have a compelling use case, I think this is a nice to have, but lower priority feature. I will add it to the spec anyway. Let me know if you know of any specific use case we should consider. * One can still use temporal operators to further constrain sequences of events: {code}$a : A() -> $b : B( this after[0,10s] $a ){code} I don't think it would be good to allow, at this point, further parameterization of the -> CE by itself. Basically, what the -> CE defines is a state machine/automaton, and that can be constrained as necessary by the patterns themselves with both temporal and non-temporal constraints. What do you think? * The problem of using the [] after the pattern type is that it become ambiguous with array types: A[*] ---> is this an array of A's with a typo or does it mean matching a repetition of A's? The "exists[+] A()" is feasible, just more verbose... do you think it would be worth writing a keyword there all the time? h5. Section 4.1 Yes, it is a step towards what you asked before... probably 80% of the way, but we would still need a few more things to get where you want... nevertheless, one feature that serves 2 purposes. h5. Section 5.5 The main difference is in semantics: event qualifiers only work with event sequencing. They are not Conditional Elements, like the "not" CE. That is the reason I can't decide between overloading the use of "not" or using a different keyword. In any case, all qualifiers are used in sequences of events, not in regular patterns. I actually need to check if there is any syntax ambiguity that I haven't identified yet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Edson Tirelli commented on JBRULES-3514: ---------------------------------------- {quote} What about allowing this, instead? declare event Ev // declaration here end define Ev as // LHS-like definition here end {quote} Seems to me that you are proposing the same thing that is already in the document, just using different keywords? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Edson Tirelli commented on JBRULES-3514: ---------------------------------------- I see what you mean and I suggest we wait to hear additional feedback on the topic. I also updated the document to include a quick overview on expiration support and entry-point reference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Wolfgang Laun edited comment on JBRULES-3514 at 5/23/12 2:19 AM: ----------------------------------------------------------------- (WL1) Section 2, re the proposed construct "event <name> as ... [insert...] end" (a) As this creates and inserts a new event fact, based on a condition similar to a rule and an implicit insert: it should also permit rule attributes? (b) It is frequently necessary to retract the matched original facts - see the phone call handling example. Consider adding a clause permitting retracts. was (Author: laune): Section 2, re the proposed construct "event <name> as ... [insert...] end" (a) As this creates and inserts a new event fact, based on a condition similar to a rule and an implicit insert: it should also permit rule attributes? (b) It is frequently necessary to retract the matched original facts - see the phone call handling example. Consider adding a clause permitting retracts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Wolfgang Laun commented on JBRULES-3514: ---------------------------------------- (WL3) Section 3 It's implied, but please state it explicitly: An "event tuple" is an "event", containing a tuple of events (and, optionally, other facts. Note that this implies that you can create event tuples containing event tuples in addition to events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Wolfgang Laun commented on JBRULES-3514: ---------------------------------------- (WL5) Subsection 5.1, binding of tuples Given the "event" declaration (Section 2): How would this interact with bindings to event tuples selected by wildcards? I see no simple way of permitting such combinations; here explicit event creation (using new) and insertion must be done. Please clarify. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Wolfgang Laun edited comment on JBRULES-3514 at 5/23/12 3:19 AM: ----------------------------------------------------------------- (WL4) Section 5, re Repetitions [*], [+] [a:b]. (a) Each of these wildcard forms implies a sequence in the sense of Section 4. However, is it "followed by" or "strictly followed by"? Note that if you define it to have either meaning, there's no simple way of expressing the other meaning. (b) What about [?] ;-) (c) It is *essential* to define whether the fildcards [*] and [+] are 'greedy' or not. (d) I think it is important to clarify whether an event type after a wildcard can be a superclass or not. Given AA extends A, does "[*]A() -> AA()" (with "greedy" [*]) ever complete? was (Author: laune): (WL4) Section 5, re Repetitions [*], [+] [a:b]. Each of these wildcard forms implies a sequence in the sense of Section 4. However, is it "followed by" or "strictly followed by"? Note that if you define it to have either meaning, there's no simple way of expressing the other meaning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Wolfgang Laun commented on JBRULES-3514: ---------------------------------------- (WL8) Subsection 6.2 (a) Who is going to want an operator where you don't know the result? (b) Given that "any A() -> any C()" has a "possible (!) result" [A1, C1], why has "every( any A() -> any C() )" an exact result - "X1 = [A1, C1], X2 = [A4, C3]" is presented as a well-defined result. (And why does this only produce 2 results - there are A1,A2,A3 and C1, C2, C3?) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Wolfgang Laun edited comment on JBRULES-3514 at 5/23/12 4:03 AM: ----------------------------------------------------------------- (WL8) Subsection 6.2 (a) Who is going to want an operator where you don't know the result? (b) Given that "any A() -> any C()" has a "possible (!) result" [A1, C1], why has "every( any A() -> any C() )" an exact result - note that "X1 = [A1, C1], X2 = [A4, C3]" is presented as a well-defined (!) result. (And why does this only produce 2 results - there are A1,A2,A3 and C1, C2, C3?) was (Author: laune): (WL8) Subsection 6.2 (a) Who is going to want an operator where you don't know the result? (b) Given that "any A() -> any C()" has a "possible (!) result" [A1, C1], why has "every( any A() -> any C() )" an exact result - "X1 = [A1, C1], X2 = [A4, C3]" is presented as a well-defined result. (And why does this only produce 2 results - there are A1,A2,A3 and C1, C2, C3?) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Wolfgang Laun commented on JBRULES-3514: ---------------------------------------- (WL11) Section 7 (a) Will there be a way to avoid the frequently seen confusion arising from window:length(N) being satisfied for any count n, 1 <= n <= N? Apparently not, if "20e" is being defined as syntactic sugar for "window:length(20)". (b) Why should the first event in a sequence not be subject to a window constraint? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Edson Tirelli edited comment on JBRULES-3514 at 5/23/12 11:59 AM: ------------------------------------------------------------------ Wolfgang, thank you for all the valuable feedback. My notes: * *(WL1)*, *(WL2)* : added to the document. * *(WL3)* : an event tuple is not an event by itself, but share some of the same properties as events. Clarified that on the document, let me know if it is still confusing. * *(WL4)* : added your suggestions, clarified your concerns and added the operators ~> and \\. * *(WL5)* : not sure if I understood your concern, but if the user needs anything out of the ordinary, he can always revert to explicit rules creating and inserting the events. With pattern repetition, the user is usually not interested in the individual events as they are most of the time repetitions, but I added a property to the Tuple type to return the list of matched events in case the user wants to keep them around. * *(WL6)* : (a) agreed and fixed. (b) the properties are just synonyms to the corresponding indexes making them easier to read, so I would like to keep them around. (c) just an explicit access to the iterator, but I agree the Tuple should be Iterable in order to enable the use of the simplified for loop syntax. * *(WL7)* : this is a discussion I've been having with the rest of the team. The reason I am advocating that "every" should be the default is because we are unifying CEP and BRE concepts and our heritage is BRE. In BRE, A() means "every A". Now imagine that you have an event A and a fact X. If every is not the default, the user writing {code}A() and X() {code} Would have to read that as "any A with every X"? This is totally confusing IMO. The default should be the same, does not matter if one is dealing with events of regular facts (after all, we define events as facts with additional semantics). I agree that it makes no sense to match every combination of SxE, so your event would be defined as: {code}event X as A() -> first C() end{code} If you compare to your original suggestion, it is just a matter of which keyword you add: {code}event X as every A() -> C() end{code} I am open to further discussions on this, but at the moment, I feel the confusion of having different defaults for events and facts trumps the other arguments... was (Author: tirelli): Wolfgang, thank you for all the valuable feedback. My notes: (WL1), (WL2) : added to the document. (WL3) : an event tuple is not an event by itself, but share some of the same properties as events. Clarified that on the document, let me know if it is still confusing. (WL4) : added your suggestions, clarified your concerns and added the operators ~> and \\. (WL5) : not sure if I understood your concern, but if the user needs anything out of the ordinary, he can always revert to explicit rules creating and inserting the events. With pattern repetition, the user is usually not interested in the individual events as they are most of the time repetitions, but I added a property to the Tuple type to return the list of matched events in case the user wants to keep them around. (WL6) : (a) agreed and fixed. (b) the properties are just synonyms to the corresponding indexes making them easier to read, so I would like to keep them around. (c) just an explicit access to the iterator, but I agree the Tuple should be Iterable in order to enable the use of the simplified for loop syntax. (WL7) : this is a discussion I've been having with the rest of the team. The reason I am advocating that "every" should be the default is because we are unifying CEP and BRE concepts and our heritage is BRE. In BRE, A() means "every A". Now imagine that you have an event A and a fact X. If every is not the default, the user writing A() and X() Would have to read that as "any A with every X"? This is totally confusing IMO. The default should be the same, does not matter if one is dealing with events of regular facts (after all, we define events as facts with additional semantics). I agree that it makes no sense to match every combination of SxE, so your event would be defined as: event X as A() -> first C() end If you compare to your original suggestion, it is just a matter of which keyword you add: event X as every A() -> C() end I am open to further discussions on this, but at the moment, I feel the confusion of having different defaults for events and facts trumps the other arguments... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Edson Tirelli edited comment on JBRULES-3514 at 5/23/12 1:08 PM: ----------------------------------------------------------------- * *(WL8)* : *(a)* Lol! My wording in there might be bad, but if the user wrote "any A()", then he does not care about which A the engine picks as long as it picks one. :) It is like conflict resolution in rule activations where all the used conflict resolution strategies are "tied" for a set of activations... it shouldn't matter which one the engine picks first, since the user defined it that way. If the user requires a specific event to be considered, then he should write his rules as so using other qualifiers. *(b)* I clarified that the current implementation of "any" will pick the first event that matches the pattern. Regarding why only 2 results, it is because of the semantics of every(): once the first match is found ([A1,C1]), every instructs the engine to look for a new match, and according to the sequence of events in our sample stream, the next A event after the match is complete on C1 is A4, followed by C3, resulting in the second match of [A4,C3]. Please note that it all depends on how the qualifiers are used. E.g., if the user would write "every A() -> any C()" then "every" would apply to "A()" only and not the whole expression (please note the lack of parenthesis). In this case, it would start a new match for every A() instead of only starting a new match after the first match is completed. * *(WL9)* : I agree with you that consuming events is probably the most common use case, but it is not the only one. I added the "retract" syntax to the proposed "event" construct and I also added a note to consider adding the "next" keyword as well as it is very compact. * *(WL10)* : Lol, I changed the "insert into" syntax to go before the definition as you proposed. The problem with "from" is that it is ambiguous to use in the way you propose. If we use a different keyword, it would be possible to write it at the end of the construct. Will think about this a bit more. * *(WL11)* : (a) yes, this is being addressed under a different work, but you raise a good point as a delimiter might be required after all. Let me think a bit more about it. (b) it is possible to add a window to the first event in a sequence, it is just redundant... it is like in a traditional rule in Drools 5.4, writing "X() over window:...(...)" without wrapping that into a complex CE like an accumulate... all X events will match because the clock is assumed to be sychronized and all X events will then be in the window scope at the time they are inserted. Thanks for all the valuable comments and contributions so far. Let me know if I missed something. was (Author: tirelli): * *(WL8)* : *(a)* Lol! My wording in there might be bad, but if they user wrote "any A()", then he does not care about which A the engine picks as long as it picks one. :) It is like conflict resolution in rule activations where all the used conflict resolution strategies are "tied" for a set of activations... it shouldn't matter which one the engine picks first, since the user defined it that way. If the user requires a specific event to be considered, then he should write his rules as so using other qualifiers. *(b)* I clarified that the current implementation of "any" will pick the first event that matches the pattern. Regarding why only 2 results, it is because of the semantics of every(): once the first match is found ([A1,C1]), every instructs the engine to look for a new match, and according to the sequence of events in our sample stream, the next A event after the match is complete on C1 is A4, followed by C3, resulting in the second match of [A4,C3]. Please note that it all depends on how the qualifiers are used. E.g., if they user would write "every A() -> any C()" the every would apply to A() only and not the whole expression (please note the lack of parenthesis). In that case, it would start a new match for every A() instead of only starting a new match after the first match is completed. * *(WL9)* : I agree with you that consuming events is probably the most common use case, but it is not the only one. I added the "retract" syntax to the proposed "event" construct and I also added a note to consider adding the "next" keyword as well as it is very compact. * *(WL10)* : Lol, I changed the "insert into" syntax to go before the definition as you proposed. The problem with "from" is that it is ambiguous to use in the way you propose. If we use a different keyword, it would be possible to write it at the end of the construct. Will think about this a bit more. * *(WL11)* : (a) yes, this is being addressed under a different work, but you raise a good point as a delimiter might be required after all. Let me think a bit more about it. (b) it is possible to add a window to the first event in a sequence, it is just redundant... it is like in a traditional rule in Drools 5.4, writing "X() over window:...(...)" without wrapping that into a complex CE like an accumulate... all X events will match because the clock is assumed to be sychronized and all X events will then be in the window scope at the time they are inserted. Thanks for all the valuable comments and contributions so far. Let me know if I missed something. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] Michael Anstis updated JBRULES-3514: ------------------------------------ Fix Version/s: 5.5.0.CR1 (was: 5.5.0.Beta1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira