Next in thread →
Next in month →
Re: [sca-bpel] NEW ISSUE: SBPEL2022 has an incorrect 'MAY' and isnot applied recursively
Title: Re: [sca-bpel] NEW ISSUE: SBPEL2022 has an incorrect 'MAY' and is not applied recursively I need to be an algorithm :-) I think I meant Scope1 shipping _shipping_2 receiving _receiving_2 Scope2 shipping receiving _shipping_1 _receiving_1 unless that doesn't work either, in which case I meant whatever points out the problem :-) Anish Karmarkar wrote: " type="cite"> 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://:143/fetch%3EUID%3E/Sent%20Items%3E27924#BPEL2019_T>] > When multiple partner links share the same name, the scheme defined by > [SBPEL2020 > <imap://:143/fetch%3EUID%3E/Sent%20Items%3E27924#BPEL2020>]-[SBPEL2022 > <imap://: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://: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://: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://: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 S/MIME Cryptographic Signature
Next in thread →
Next in month →