[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]