Subject: Issue 81 - Proposal For Vote
Summary: Explicitly require that initial activities be start activities. Section 6.5 Change: To be instantiated, each business process must contain at least one such "start activity." This must be an initial activity in the sense that there is no basic activity that logically precedes it in the behavior of the process. To: To be instantiated, each business process must contain at least one such "start activity." That is, a receive/pick activity annotated with a createInstance="yes" attribute. See section 11.4 for more details on start activities. Change: If exactly one start activity is expected to instantiate the process, the use of correlation sets is unconstrained. To: If a process contains exactly one start activity then the use of correlation sets is unconstrained. Section 11.4 Change: A receive activity annotated in this way MUST be an initial activity in the process, that is, the only other basic activities may potentially be performed prior to or simultaneously with such a receive activity MUST be similarly annotated receive activities. To: A receive/pick activity annotated in this way MUST be a "start activity". A "start activity" is a receive/pick activity that is marked with a createInstance="yes" attribute where no other activities but scope, flow, sequence or empty activities occur before it in the execution path rooted at the process element. Change: It is permissible to have the createInstance attribute set to"yes" for a set of concurrent initial activities. To: It is permissible to have multiple start activities. As specified in section 6.5 the initial start activity must complete execution before any other start activities are allowed to execute. Change: All such receive activities MUST use the same correlation sets (see Correlation). To: If a process has multiple start activities then all the start activities MUST use the same correlation sets and the pattern for all the correlation sets MUST be sent to "rendezvous" (see Correlation).