← Prev in month
← Prev in thread
RE: [sca-bpel] [ISSUE 64]: Name of the generated SCA reference fora partnerLink declared with multiRefFrom extension
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:] Sent: Wednesday, August 18, 2010 11:54 PM To: Subject: [sca-bpel] [ISSUE 64]: Name of the generated SCA reference for a partnerLink declared with multiRefFrom extension This is issue 64. http://osoa.org/jira/browse/BPEL-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: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php sca-bpel-1.1-spec-cd02-rev9-issue64.doc
← Prev in month
← Prev in thread