Attached is the CD2Rev9 document along with the proposed changes for resolving the Issue 64.
The proposed changes are in sections 3.2.1 and 3.3, which I am also including here for your convenience:
2.3.1 Algorithm for Generating Unique SCA Service and Reference Names
Algorithm:
- Let S be the set of names of SCA services and references generated from introspecting the BPEL process definition as defined in section ý2.1.1, at any given point in
time.
- At the start of the introspection, S is empty.
- The BPEL process is examined in lexical order for occurrences of partnerLinks
and multi-valued variableswhich do not have the sca-bpel:ignore attribute with a value of ‘true’. - For each partnerLink
or multi-valued variable that is encountered:
- If the sca-bpel:service or sca-bpel:reference attribute is present on the partnerLink, its value MUST NOT be a member of S. The value of the attribute is added to S and an SCA service or reference added to the
componentType of the BPEL process as defined in section ý2.1.1.
Else if the name attribute is present on the sca-bpel:multiReference extension element of a variable, its value MUST NOT be a member of S. The value of the attribute is added
to S and an SCA reference is added to the componentType of the BPEL process as defined in section ý2.1.1.- Else if the name of the partnerLink is not a member of S, then the name is added to S and an SCA service or reference is added to the componentType of the BPEL process as defined in section ý2.1.1.
- Else if the name of the partnerLink is already present in S, the name is prefixed and suffixed with the "_" character. In addition, the name is also suffixed with additional characters that represent the smallest positive
integer without any leading zero(s), which results in a name that does not conflict with any existing member of S. The resulting name is added to S an SCA service or reference is added to the componentType of the BPEL process as defined in section ý2.1.1.
- Partner Link Mapping to Services and References
….
[SBPEL3020] A process MUST NOT include more than one of sca-bpel:ignore,
sca-bpel:service and sca-bpel:reference attributes on a single partner link.
A partnerLink MUST NOT have the sca-bpel:ignore attribute when an sca-bpel:service or an sca-bpel:reference or an sca-bpel:multiRefFrom attribute is also present on that partnerLink.
Thanks,
Sanjay
-----Original Message-----
From: Anish Karmarkar [
mailto:Anish.Karmarkar@oracle.com]
Sent: Wednesday, August 18, 2010 11:54 PM
To: sca-bpel@lists.oasis-open.org
Subject: [sca-bpel] [ISSUE 64]: Name of the generated SCA reference for a partnerLink declared with multiRefFrom extension
This is issue 64.
-Anish
--
On 8/18/2010 10:14 AM, Patil, Sanjay wrote:
> Title: Name of the generated SCA reference for a partnerLink declared
> with multiRefFrom extension
> Target: SCA WS-BPEL C&I Specification Version 1.1 CD 2 Rev 9
> Description:
> There is no normative statement in the specification for generating name
> of an SCA reference which corresponds to a partnerLink that uses the
> multiRefFrom extension.
> There is discrepancy in how the name of a reference is generated for a
> partnerLink with multiRefFrom extension:
>
> * Section 2.3.1 uses the name of the variable with multiReference
> extension as the name of the generated reference. See the text:
> ‘Else if the name attribute is present on the
> sca-bpel:multiReference extension …’
> * Section 3.2 uses the name of the partnerLink as the name of the
> generated reference. See the text at the bottom of the section: ‘A
> multi-value reference named “vendorLink” , which his categorized as …”
>
> Proposal:
> Add a normative statement after the SBPEL2024 statement: The name of the
> reference MUST be the value of the name attribute of the partnerLink.
> Update the sections 2.3.1 and 3.2 to comply with the added normative
> statement.
---------------------------------------------------------------------
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: