Re: [wsbpel] Issue 109: Proposal to Vote - Compatibility betweenAbstract and Executable Processes

[Rania Khalaf <rkhalaf@watson.ibm.com>]

Hi Monica,

I am having trouble reading the sentence. Perhaps part of the email got 
truncated ?

How about adding:

"an executable process that belongs to the set of permitted executable 
completions specified in the profile of a particular abstract process is 
compatible with that abstract process"

The constraints are already part of the 'permitted executable 
completions' so no need to mention them. However, my question then is 
what about non-BPEL implementations? If we start the talk of conformance 
do we have to address those as well since we allow them ?

Also, when you say 'map to issue xxx' do you mean 'drop since already 
handled by issue xxx' ?  I think the latter wording is clearer if that 
is what is meant.

My preference would be to close this issue without change to the spec 
since most of it is handled elsewhere and I'd like to avoid the 
conformance discussion. I would be able to live with adding the sentence 
above and closing the other 'pieces' of it. My concern there is 
regarding compliance then of non-BPEL as I state above but if the TC is 
willing to live with that I won't fight too hard.

Regards,
Rania


Monica J Martin wrote:

> Reference: 
> http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue109
>
> Issue 109 is handled in part by Issue 82 and its subissues, 82.1-.3.  
> For example, they are related (but not subject to any requested 
> dependency, i.e. there is no requirement that other subissues must be 
> closed before 109 is):
>
>    * Map to Issue 82. Reason: Reference to executable completion.
>    * Map to Issue 82.1. Reason:  Ensures syntax and validation of
>      abstract BPEL is consistent as applicable with the executable
>      BPEL.  Relates to compatibility.
>    * Map to Issue 82.2: Promote consistency between common base and
>      abstract process (Note: At the time this issue was written, we had
>      not identified a common base).
>    * Map to Issue 82.3. Reason: Promote consistency between any example
>      abstract process and any profile examples developed (Note: At the
>      time this issue was written, we had not identified a usage profile
>      concept).
>    * In Section 15.2 that talks about executable completion, add: 
>          o Where an abstract process is used [1], a compatible EP an
>            executable completion of the permitted completions of the
>            applicable AP profile that implements the associated
>            abstract process and its constraints if any.
>
> Rania, this is the consolidated proposal that I had forwarded to you. 
> Thank you.
>
> [1] Compatible if there is an EP and associated AP. EP could exist 
> without AP.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php