Title: RE: [sca-bpel] [Issue 41]: SBPEL2022 has an incorrect 'MAY' and is not
applied recursively
I like those changes.
From: Danny van der Rijn
[mailto:]
Sent: Friday, May 15, 2009 1:28 PM
To: Najeeb Andrabi
Cc: Michael Rowley; Anish Karmarkar; OASIS BPEL
Subject: Re: [sca-bpel] [Issue 41]: SBPEL2022 has an incorrect 'MAY' and
is not applied recursively
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
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
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:]
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:]
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
