[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]