OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]