RE: [sca-bpel] [Issue 41]: SBPEL2022 has an incorrect 'MAY' and isnot applied recursively

[Michael Rowley <michael.rowley@activevos.com>]

Actually, it is completely deterministic.  For each partner link, there is exactly one smallest positive integer that does not conflict with the names of services and references for previous partner links.

Michael

-----Original Message-----
From: Najeeb Andrabi [mailto:nandrabi@tibco.com] 
Sent: Thursday, May 14, 2009 8:59 PM
To: Michael Rowley; Anish Karmarkar; OASIS BPEL
Subject: RE: [sca-bpel] [Issue 41]: SBPEL2022 has an incorrect 'MAY' and is not applied recursively


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