Re: [sca-bpel] NEW ISSUE: SBPEL2022 has an incorrect 'MAY' and isnot applied recursively

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Danny van der Rijn wrote:
> [changing subject to include issue #]
> 
> As we discussed on the call, we need to do 2 things:
> 
> 1 - decide what it is we actually want the spec to require here
> 2 - come up with language that specifies that
> 
> IMO it will be much easier to do #1 if we don't do #2 at the same time.

+1

> I'll take a stab at what it is we want to do, using an illustrative (and 
> pathological) example.
> 
> Imagine a process with the following (scopes and) partnerLinks:
> 
> Scope1
>     shipping
>     _shipping_2
>     receiving
>     _receiving_2
>    
> Scope2
>     _shipping_1
>     _receiving_1
>    

Where is the collision here? They all have unique names.

> 
> As context, here's section 2.3:
> 
> "It is possible to declare partner links local to a <scope> in WS-BPEL, 
> besides declaring partner links at the <process> level. The names of 
> partner link declared in different <scope> could potentially share the 
> identical name. [SBPEL2019 
> <imap://TSI-PA%5Cdannyv@imap1.tibco.com:143/fetch%3EUID%3E/Sent%20Items%3E27924#BPEL2019_T>] 
> When multiple partner links share the same name, the scheme defined by 
> [SBPEL2020 
> <imap://TSI-PA%5Cdannyv@imap1.tibco.com:143/fetch%3EUID%3E/Sent%20Items%3E27924#BPEL2020>]-[SBPEL2022 
> <imap://TSI-PA%5Cdannyv@imap1.tibco.com:143/fetch%3EUID%3E/Sent%20Items%3E27924#BPEL2022>] 
> MUST be used to disambiguate different occurrences of partner link 
> declaration.
> 
> ·          Let "originalName" be the original NCName used in multiple 
> partner link declarations.
> 
> ·          [SBPEL2020 
> <imap://TSI-PA%5Cdannyv@imap1.tibco.com:143/fetch%3EUID%3E/Sent%20Items%3E27924#BPEL2020_T>] 
> The introspected component type MUST include services or references 
> corresponding to these partner links with names: "_orginalName_1" to 
> "_orginalName_N". Whether the partner link corresponds to a service or 
> reference does not affect the name used. [SBPEL2021 
> <imap://TSI-PA%5Cdannyv@imap1.tibco.com:143/fetch%3EUID%3E/Sent%20Items%3E27924#BPEL2021_T>] 
> The number suffixes for the partner links MUST be based on the lexical 
> order of the corresponding partner link occurrences in the process 
> definition.
> 
> ·          [SBPEL2022 
> <imap://TSI-PA%5Cdannyv@imap1.tibco.com:143/fetch%3EUID%3E/Sent%20Items%3E27924#BPEL2022_T>] 
> If any "_orginalName_i" (where 1 <= i <= N) is already the name of a 
> partner link declaration in the process definition, additional 
> underscore characters MAY be added at the beginning of all aliases 
> consistently to avoid collision."
> 
> 
> I read the above rules as resulting in the following:
> 
> Scope1
>     shipping         <-  _shipping_1
>     _shipping_2   <- __shipping_2_1
>     receiving         <- _receiving_1
>     _receiving_2   <- __receiving_2_1
>    
> Scope2
>     shipping         <- _shipping_2
>     receiving         <- _receiving_2
>     _shipping_1   <- __shipping_1_1
>     _receiving_1   <- __receiving_1_2
> 
> 
> Note:  This solution is not handled in a single-pass.  Would a 
> single-pass solution be preferable?
> 
> I'm not sure that this is the prettiest solution, but then again, I'm 
> not sure I care.  I'd welcome other solutions, as well as other 
> interpretations of the text.  However, all that is truly important, IMO, 
> is that we agree on what we want (#1) and then do our best to encode it 
> (#2).  If #2 proves too difficult for our decision on #1, then I propose 
> we change #1.
> 
> Danny
> 
> 
> 
> Danny van der Rijn wrote:
>> If you're going down to this level of detail, I think you need to be 
>> more explicit about what "recursive"  and (where 1 <= i <= N) mean.  
>> Something like
>>
>> "If any "_originalName_i" (where N is the number of partnerLinks of 
>> name 'originalName', 1 <= i <= N) is already the name of a partner 
>> link declaration in the process definition, then the smallest number 
>> of additional underscore characters MAY  MUST be added at the 
>> beginning of all aliases originalNames, consistently to avoid 
>> collision, to avoid a collision."
>>
>>
>>
>> Anish Karmarkar wrote:
>>> Title: SBPEL2022 has an incorrect 'MAY' and is not applied recursively
>>>
>>> Target: SCA BPEL C&I PR 01
>>>
>>> Description:
>>> SBPEL2022 states the following:
>>> "If any "_orginalName_i" (where 1 <= i <= N) is already the name of a 
>>> partner link declaration in the process definition, additional 
>>> underscore characters MAY be added at the beginning of all aliases 
>>> consistently to avoid collision."
>>>
>>> 'MAY' here means that some runtimes may not choose to do this. We 
>>> want deterministic names that are independent of the runtime.
>>>
>>> It is also possible that after an additional underscore is added at 
>>> the beginning it still results in a conflict. SBPEL2022 needs to be 
>>> applied recursive till there is no collision.
>>>
>>> Proposal:
>>>
>>> Replace SBPEL2022 with --
>>> "If any "_orginalName_i" (where 1 <= i <= N) is already the name of a 
>>> partner link declaration in the process definition, then an 
>>> additional underscore characters MAY  MUST be added at the beginning 
>>> of all aliases names, recursively, consistently to avoid collision, 
>>> until a collision is avoided."
>>>
>>> (alternately, we can say something along the lines of "... additional 
>>> minimum number of underscore characters that results in no collision 
>>> MUST be added at the beginning of all names consistently."
>>>
>>> -Anish
>>> --
>>>
>>> --------------------------------------------------------------------- 
>>> To unsubscribe from this mail list, you must leave the OASIS TC that 
>>> generates this mail. Follow this link to all your TCs in OASIS at: 
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php