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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

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


Subject: Re: [sca-bpel] [Issue 41]: SBPEL2022 has an incorrect 'MAY' and isnot applied recursively


I think we are close.
There are two things that need to be fixed:
1) I don't think _originalName_1 and _originalName_N make any sense 
(they are not defined in any case). We should just talk about 
_originalName_i, where i is the smallest positive integer that is large 
enought ...
2) It does not say anything about using this algorithm on partnerlink in 
the lexical order. Without the requirement for the lexical order we'll 
not get deterministic CT. (more on this in the inlined comment below.

Danny van der Rijn wrote:
> After talking with Najeeb, I agree with his objection to the word 
> "choosing" implying that there is a choice.  We suggest changing 
> Michael's excellent proposal by removing that word from the proposal:
> 
>           The number suffix generated for a partner link MUST be 
> generated by choosing the smallest integer that is large enough so that 
> the resulting name does not conflict with the service or reference name 
> of any /previous/ partner link in the process.
> 
> Document enclosed that does that, fixes the "orginal" typos, removes a 
> colon, and changes "integer" to "positive integer"
> 
> To see what this proposal would do to my pathological example:
> 
> Scope1
>      shipping            -> shipping
>      _shipping_2         -> _shipping_2
>      receiving           -> receiving             
>      _receiving_2        -> _receiving_2
>    
>   Scope2
>     shipping             -> _shipping_1
>     receiving            -> _receiving_1
>     _shipping_1          -> __shipping_1_1
>     _receiving_1         -> __receiving_1_1
> 

I don't think this is right OR at the very least I see this as a bad 
outcome if it is in fact right.

original name _shipping_1 does not have a conflict and should not be 
mangled. I believe this is what we want:

Scope1
      shipping            -> _shipping_3
      _shipping_2         -> _shipping_2
      receiving           -> _receiving_3
      _receiving_2        -> _receiving_2

Scope2
      shipping             -> _shipping_4
      receiving            -> _receiving_4
      _shipping_1          -> _shipping_1
      _receiving_1         -> _receiving_1

> and if we make it slightly differently pathologically tailored to this 
> algorithm:
> 
> Scope1
>      shipping            -> shipping
>      _shipping_2         -> _shipping_2
>      receiving           -> receiving             
>      _receiving_2        -> _receiving_2
>    
>   Scope2
>     _shipping_1          -> _shipping_1
>     _receiving_1         -> _receiving_1
>     shipping             -> _shipping_3
>     receiving            -> _receiving_3
> 

I think this should be:
Scope1
      shipping            -> _shipping_3
      _shipping_2         -> _shipping_2
      receiving           -> _receiving_3
      _receiving_2        -> _receiving_2

Scope2
      _shipping_1          -> _shipping_1
      _receiving_1         -> _receiving_1
      shipping             -> _shipping_4
      receiving            -> _receiving_4

> 
> Danny
> 
> Najeeb Andrabi wrote:
>>
>> I thought the idea behind uniqueness of partner link names was that the
>> introspected/inferred component type will have deterministic and unique
>> service or reference names so that they can be ported across SCA
>> runtimes. Randomly choosing a small integer to make partner link names
>> unique makes them in-deterministic.
>>
>> I had suggested in the last meeting that may be better approach would be
>> to let the uniqueness of partner link names be left to the user. I did
>> not realize at that time that user can add SCA constructs based on the
>> derived unique name of the partner link.
>>
>> --Najeeb
>>
>>
>>
>> -----Original Message-----
>> From: Michael Rowley [mailto:michael.rowley@activevos.com]
>> Sent: Thursday, May 14, 2009 12:47 PM
>> To: Anish Karmarkar; OASIS BPEL
>> Subject: RE: [sca-bpel] [Issue 41]: SBPEL2022 has an incorrect 'MAY' and
>> is not applied recursively
>>
>> It is too hard to handle this out of context, so here is a proposal that
>> is a change marked version of 2.3.
>>
>> Michael
>>
>> -----Original Message-----
>> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
>> Sent: Wednesday, May 06, 2009 5:53 PM
>> To: OASIS BPEL
>> Subject: [sca-bpel] [Issue 41]: SBPEL2022 has an incorrect 'MAY' and is
>> not applied recursively
>>
>> Is now issue 41
>> http://osoa.org/jira/browse/BPEL-41
>>
>> -Anish
>> --
>>
>> 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
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>


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