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 - 139.1 - Proposal For Vote


On your first question I think you found what is in essence old text 
left over from a previous iteration and I will take it as a friendly 
amendment to remove it.

As for the second, that was a typo.

	Yaron

Prasad Yendluri wrote:
> Hi,
> 
> Couple of comments / questions on the proposal:
> 
> 1.
>  >From: In the degenerate case where a partnerLinkType has only one role, one of 
> these attributes is omitted as >appropriate.
>  >
>  >To: In the case where a WSDL binding is only specified for one of the two 
> roles then one of these attributes is omitted as appropriate.
> 
> I don't understand the need for this change or I don't think this is accurate.  
> The original text, I believe is referring to the fact that the partnerLinkType 
> for this partnerLink (identified in @partnerLinkType) MAY have been defined with 
> only one role. See partnerLinkType syntax below.
> 
> <definitions name="ncname" targetNamespace="uri"
>      xmlns="http://schemas.xmlsoap.org/wsdl/";>
>         ...
>      <plnk:partnerLinkType name="ncname">
>           <plnk:role name="ncname" portType="qname"/>
>    *       **<plnk:role name="ncname" portType="qname"/>?*
>      </plnk:partnerLinkType>
>         ...
> </definitions>
> 
> So one of the roles not being present on a partnerLink has no relation to WSDL 
> binding and tying this to WSDL binding is not correct IMO. I would suggest we 
> not make this change and keep the original text.
> 
> 2. I like to make @initializePartnerRole optional and present only when the 
> @partnerRole is present. The proposed syntax shows it to be mandatory.
> 
> Regards, Prasad
> 
> Yaron Y. Goland wrote:
> 
>> Note: Had to remove "may" as an option in the BNF, it was a left over from a 
>> previous version of the proposal. Thanks to Danny for pointing this out.
>>     Yaron
>>
>> Issue 139.1: How/when BPEL can change partner role EPR
>>
>> Proposal: Put in a switch to specify if the programmer is depending on the 
>> BPEL processor to initialize a partnerRole value on a partnerLink. This switch 
>> has no affect on the engine's behavior after the partnerLink is used for the 
>> first time.
>> Section 7.2
>>
>> Change the BNF to read:
>>
>> <partnerLinks>
>>      <partnerLink name="ncname" partnerLinkType="qname"
>>           myRole="ncname"? partnerRole="ncname"?
>>           initializePartnerRole="yes|no">+
>>      </partnerLink>
>> </partnerLinks>
>>
>> *From: In the degenerate case where a partnerLinkType has only one role, one 
>> of these attributes is omitted as appropriate.
>>
>> To: In the case where a WSDL binding is only specified for one of the two 
>> roles then one of these attributes is omitted as appropriate. *
>>
>> Insert the following as a new paragraph after the paragraph that ends with " 
>> See Assignment for the mechanisms used for dynamic assignment of endpoint 
>> references to partner services."
>>
>> The initializePartnerRole attribute specifies if the BPEL processor is 
>> required to initialize a partnerLink's partnerRole value. The attribute has no 
>> affect on the partnerRole's value after its initialization. The 
>> initializePartnerRole attribute MUST NOT be used on a partnerLink that does 
>> not have a partner role; this restriction MUST be statically enforced.
>>
>> If the initializePartnerRole attribute is set to "yes" then the BPEL processor 
>> MUST initialize the EPR for the specified partnerLink/partnerRole combination 
>> before that partnerRole is first referenced by the BPEL process.
>>
>> If the initializePartnerRole attribute is set to "no" then the BPEL processor 
>> MUST NOT initialize the EPR for the specified partnerLink/partnerRole 
>> combination before that partnerRole is first referenced by the BPEL process.
>>
>> If the initializePartnerRole attribute is omitted then its value MUST be 
>> treated as "no".
> 



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