Title: 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:
"
type="cite">
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
issue41vdR.doc
S/MIME Cryptographic Signature
