[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 287 - Uniqueness of Scope Names
As promised, some considerations for activity name uniqueness. The goal of this issue (as well as 162) is to avoid ambiguities for the <compensateScope target="xxx"/> activity. There exists a hierarchy of options for the range of activity uniqueness (some more, some less useful): 1. nothing is validated and ambiguities are acceptable (this creates a new type of compensation handler instance group) 2. nothing is validated and a new standard fault is thrown when an ambiguity is encountered (undesirable because we can validate) 3. only the names used in compensateScope must be unique (<--- this is IBM's favorite) 4. all named scopes "immediately enclosed" in another scope must be unique (<--- this is the current submitter's proposal for 287) 5. all named activities "immediately enclosed" in another scope must be unique (requires a definition of "immediately enclosed" activities) 6. all named scopes in the process must be unique 7. all named activities in the process must be unique 8. all scopes in the process must be uniquely named 9. all activities in the process must be uniquely named Note that in the above, "scopes" includes those scopes that are implicitly created by an invoke with CH or FH, i.e. "scopes" includes these invokes. Kind Regards DK Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220 Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany ws-bpel issues list editor <peter.furniss@er To ebor.co.uk> wsbpel@lists.oasis-open.org cc 14.05.2006 20:35 Subject [wsbpel] Issue - 287 - Uniqueness Please respond to of Scope Names wsbpel@lists.oasi s-open.org This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if a motion to open the issue is proposed and that motion is approved by the TC. A motion could also be proposed to close it without further consideration. Otherwise it will remain as "received". The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL. Issue - 287 - Uniqueness of Scope Names Status: received Date added: 14 May 2006 Date submitted: 12 May 2006 Submitter: Dieter Koenig1 Document: WS-BPEL 2.0 Committee Draft, sections 10.1. and 12.4.3. Description: Background: the original objective of issue 162 was to avoid ambiguities for the <compensateScope> activity. If the <compensateScope> activity is not present, there is no need for any constraint, so the following example is perfectly acceptable: scope pick name="Pick" onMessage assign name="PopulateVariableX" onMessage assign name="PopulateVariableX" As a result of the amended resolution of issue 162 : Unique Activity Names for Compensate , section 10.1. defines that "The name of a named activity MUST be unique amongst all named activities present within the same immediately enclosing scope. This requirement MUST be statically enforced.". There is no definition of "immediately enclosed activities", and the text is not clear enough as scopes only have one primary activity. If all (transitively) "enclosed activities" were meant then the sentence would imply that the names of all named activities in a process must be unique, which was not the intention of 162. As a result of the resolution of issue 275 : "immediately enclose" and compensation , section 12.4.3. now defines that "For the purpose of specifying the semantics of <compensate> and <compensateScope>, a scope, A is considered to immediately enclose another scope, B, if B is enclosed in A and B is not enclosed in any other scope or FCT-handler that is itself enclosed in the outer scope A. Other structured activities (e.g. <sequence> or <forEach>) and event handlers enclosed in A do not affect the concept of immediate enclosure". This definition is VERY CLOSE to what is really needed as a resolution for 162. It should be made clear that the concept of an "immediately enclosed" scope includes scopes that result from the <invoke> shorthand notation for fault handlers and compensation handlers. Submitter's proposal: Note: the TC should be aware that the following proposal partially reverses the amendment of 162 in restricting the constraint to scopes only. 1. Replace the quoted sentences from section 10.1. by a reference: "See section 12.4.3. for uniqueness constraints of the name attribute." 2. Add to the quoted sentence in section 12.4.3.: "This definition includes scopes that result from the <invoke> shorthand notation for fault handlers and compensation handlers. Within a scope, the name of all named immediately enclosed scopes MUST be unique. This requirement MUST be statically enforced." Changes: 14 May 2006 - new issue To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 287 - [anything]" or is a reply to such a message. If you want to formally propose a resolution to an open issue, please start the subject line "Issue - 287 - Proposed resolution", without any Re: or similar. To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement). --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]