RE: [wsbpel] Issue 44 - Summary so far.

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

The process rules explicitly allow the group to vote to re-open an issue in
which case the group can then subsequently vote to close it with a different
resolution.

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Thursday, October 16, 2003 11:06 AM
> To: Liu, Kevin; Marin, Mike; wsbpel@lists.oasis-open.org
> Cc: ygoland@bea.com
> Subject: RE: [wsbpel] Issue 44 - Summary so far.
> 
> 
> It is true that we have in fact made other decisions recently that
> maintain some redundancy, e.g., in resolving Issue 36.  
> 
> We would need to change this for all constructs that use 
> patrnerLink and
> portType, including invoke, receive, pick and event handlers, and of
> course all the examples.  Now that I look at the way the resolution is
> worded this is not clearly stated.  That alone is justification for
> reopening the issue or asking for clarification.  But this issue is
> currently resolved.  We do not have a process for reopening it.  If we
> want to reverse the decision we would have to open a new 
> issue.  Opening
> a new issue would be justification for not doing the editorial work if
> we may have to undo it.
> 
> Opinions?  Yaron, what is your take from an issues process 
> perspective?
> 
> Satish 
> 
> -----Original Message-----
> From: Liu, Kevin [mailto:kevin.liu@sap.com] 
> Sent: Thursday, October 16, 2003 7:07 AM
> To: 'Marin, Mike'; 'wsbpel@lists.oasis-open.org'
> Cc: Satish Thatte; 'ygoland@bea.com'
> Subject: RE: [wsbpel] Issue 44 - Summary so far.
> 
> Hi guys,
> 
> I need a few clarifications/confirmations before I start to really
> change the spec to reflect this resolution.
> 
> 1. Does it really help to remove the portType attribute? 
> 
> After the removal, the new syntax looks like
> 
> <invoke partnerLink="ncname" operation="ncname"
>     inputVariable="ncname"? outputVariable="ncname"?
>     standard-attributes>
> 
> It does need the portType information to make operation, input, output
> meaningful. It's true that the portType info is inferable from
> partnerLink, but what harm does it cause to duplicate it here 
> if we make
> it clear that the portType here must be consistent with the 
> portType in
> parterLink? 
> 
> 2. What's the impact on other constructs?
> If we change it for invoke, same should also apply to <receive> (and
> maybe more?). Does this resolution cover that?
> 
> Let alone the non-trivial editorial work - almost all the 
> example codes
> in the spec need to be changed to get rid of the portType attribute, I
> am concerned about the uncertain impact on <receive> and maybe other
> constructs and the "corner cases" left uncovered (issue 52 is still
> open).  
> 
> It seems to me we could go for a simpler solution  - just add
> clarification text to <invoke> definition and make it clear that the
> invoke@portType must be consistent with partnerlink.
> 
> Not intended to reopen the issue, but just want to make sure that the
> above concerns have already been considered
> 
> Best Regards, 
> Kevin 
> 
> 
> -----Original Message-----
> From: Marin, Mike [mailto:MMarin@filenet.com] 
> Sent: Tuesday, August 19, 2003 12:11 PM
> To: ygoland@bea.com; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 44 - Summary so far.
> 
> 
> To keep things clean, I will remove proposal two from issue 
> 44, and let
> keep issue 52 for calling yourself. That way there is only 
> one proposal
> for issue 44 as follows:
> 
> Issue 44 - Proposal: Just remove the portType from the invoke activity
> and use the portType that corresponds to the partnerRole in the
> partnerLink. This covers most if not all the use cases. With the only
> exception of a process that wants to call itself, which is 
> discussed by
> issue 52.
> 
> --
> Regards,
> Mike Marin
> 
> -----Original Message-----
> From: Yaron Goland [mailto:ygoland@bea.com]
> Sent: Tuesday, August 19, 2003 11:55 AM
> To: Marin, Mike; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 44 - Summary so far.
> 
> Hum... maybe I shouldn't have created Issue 52 and instead should have
> kept it part of Issue 44? I thought Issue 44 would just address the
> issue of removing the portType and that issue 52 would address how to
> deal with calling yourself. Because, given your summary below, clearly
> 52 (http://lists.oasis-open.org/archives/wsbpel/200308/msg00158.html)
> should be a 3rd option.
> 
> > -----Original Message-----
> > From: Marin, Mike [mailto:MMarin@filenet.com]
> > Sent: Monday, August 18, 2003 5:40 PM
> > To: wsbpel@lists.oasis-open.org
> > Subject: [wsbpel] Issue 44 - Summary so far...
> >
> >
> >
> > This issue deals with the fact that in the current syntax the Invoke
> > activity requires a partnerLink and a portType. However the
> > partnerLink
> > refers to a partnerLinkType, which also includes the
> > portType. Therefore
> > the portType in the Invoke is redundant. So far, there is no
> > disagreement on this analysis.
> > 
> > There are two possible solutions (or proposals):
> > 
> > 1- (proposal 1): Just remove the portType from the invoke 
> activity and
> > use the portType that corresponds to the partnerRole in the
> > partnerLink.
> > This covers most if not all the use cases. With the only
> > exception of a
> > process that wants to call itself, in which case you will
> > need to create
> > another partnerLink (using the same partnerLinkType) and use
> > it instead.
> > So, in this case you end with two partner links.
> > 
> > 2- (proposal 2): Remove the portType from the invoke 
> activity, but add
> > an optional role. When the role is specified, it must
> > correspond to one
> > of the two roles defined in the partnerLink. If the role is not
> > specified the partnerRole in the partnerLink should be assumed.
> > 
> > With this second proposal, in most cases the syntax will 
> look exactly
> > the same as with the first proposal. But, if a process needs to call
> > itself, instead of adding a partner link, it just adds a role to the
> > invoke activity.
> > 
> > Both solutions are similar and better than the current
> > syntax. The only
> > real difference is the optional role on the invoke activity
> > to preserve
> > the functionality currently specified, but that seems to be 
> uncommon.
> > 
> > Regards,
> > Mike Marin
> > 
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> 
> 
>

<<attachment: winmail.dat>>