[jboss-jira] [JBoss JIRA] (JBRULES-3514) Add support to event sequencing

[ 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