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