Re: [wsbpel] Issue - 82 - Proposal for Vote

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

Hi,
hmm tricky.
let me clarify.

my def of 82:

  It explains what abstract processes are (conceptually) in the first part.

  Then it takes a consistent view of what the semantics are, given how 
we move forward (spec and open issues).You can think of it as my take on 
a  consistent view of abstract processes given a snapshot in time.

So, it takes into account what the issues have described, but does so as 
  moving forward from explicit points in the current specification. 
That's why the points that are affected by the issues are highlighted 
(99, 107). The text for wether more of the exec process stuff can be 
moved into abstract is not there. Example: Point (C) says "currently" 
(ie in the spec today) and "pending 99". (D) says pending 99. (B) says 
"nearly all".

It does not propose changes in the architecture of abstract processes 
that are beyond the open issues or touch on open issues that are not 
relevant to the clarification requested in 82. It also does not claim to 
take into consideration every possible combination of how those 
mentioned open issues could be resolved coz then It wouldn't be 
coherent. However, it does let those issues move forward in any 
direction and new ones be opened.

  From that we can move forward on the rest of the issues and it is 
clearer to people whether or not they want new issues, what those should 
address, etc... Changes would therefore be again steps forward from the 
spec and we would know exactly where they are.

Does this help?

-Rania

Yaron Y. Goland wrote:
> Rania, for the sake of argument let's accept your definition of 82 as 
> only intending to provide design motivation for the existing features in 
> the spec. Although it's worth pointing out that many members of this TC 
> do not agree with that understanding of issue 82. It is also worth 
> pointing out that your own proposal violates this understanding of issue 
> 82 in section D where it explicitly refers to a feature, opaque, which 
> does not exist in the spec today.
> 
> But, given your definition of 82, for issue 82 to be successfully 
> resolved it must provide a design motivation for why abstract processes 
> look the way they do in the spec. Specifically, why is the feature set 
> for abstract processes different than the feature set for executable 
> processes? For example, why are query strings legal in executable 
> processes but not abstract processes?
> 
> Your proposal only reiterates the limitations in the spec without 
> explaining them. Therefore one is forced to conclude that by your own 
> definition your existing proposal does not resolve issue 82.
> 
>     Thanks,
> 
>         Yaron
> 
> 
> rkhalaf wrote:
> 
>> Hi Monica,
>>
>> This issue (#82) is that the spec is not clear in describing abstract
>> BPEL. There are several other issues that relate to abstract bpel. They
>> addresss different parts. The part that relates to definition goes into
>> this issue, and is based on several discussions including that of the
>> abstract process subgroup.
>>
>> In the TC, we move forward from the spec as the base, highlight issues
>> with it, and propose changes to address them. That's why the spec is the
>> input document to the TC, providing context to the discussion. That does
>> not preclude changes of course but those should go under the appropriate
>> issue and they move forward from the current version of the spec. This
>> is purely procedural.
>>
>> I am interested in knowing your technical objections or suggestions to
>> the actual proposal. For example, such as Yaron and Danny's comments.
>> Could you please highlight those and suggest succinctly what your
>> technical position is towards moving forward in the solution to this
>> proposed issue? I hope I addressed the ones you pointed out on the call.
>> I will try rewording E to clarify based on your comment.
>>
>> One option is to break up 82 into smaller pieces. Perhaps use only the
>> first paragraph as definition and then move on the rest of the issues
>> and then come back to it etc..
>>
>> thanks,
>> Rania
>>
>>
>> Monica J. Martin wrote:
>>  > rkhalaf wrote:
>>  >
>>  >> Hi Monica,
>>  >>
>>  >> The proposal in (1) makes abstract BPEL's syntax a strict superset of
>>  >> executable BPEL. This is not what is in the specification.
>>  >>
>>  >> The issue 82 is to clarify what abstract bpel is (mainly wordsmithing
>>  >> as the issue states) and to have a better definition not to change
>>  >> what it is or how it is.  The other issues are being used to do that
>>  >> such as 107 etc .. Changing structure goes under rearchitecting.
>>  >>
>>  > mm1: This restriction was not a part of the subgroup discussion, and
>>  > clearly was not placed on the scope of the recent TC participation 
>> until
>>  > you specified it.  Why did the subgroup spend 5+ months trying to 
>> define
>>  > it if the boundary was the specification as a gate? To coin Satish, 
>> this
>>  > is 'false economy.' Thank you.
>>
>>
> 
> To unsubscribe from this mailing list (and be removed from the roster of 
> the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. 
>