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

["Yaron Y. Goland" <ygoland@bea.com>]

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.
> 
>