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 agree.

-Anish
--

Danny van der Rijn wrote:
> I would propose that whatever we end up with, we include an illustrative 
> example in the spec, possibly with illustrative text, and include test 
> cases for it.
> 
> Anish Karmarkar wrote:
>>
>> 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]