OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue - 210 - Cleaning up naming


This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if the TC accepts it as identifying a bug in the spec or decides it should be accepted specially. Otherwise it will be closed without further consideration (but will be marked as "Revisitable")

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 - 210 - Cleaning up naming

Status: received
Date added: 24 May 2005
Categories: Syntax and validation
Date submitted: 24 May 2005
Submitter: Yaron Y. Goland
Description: Section 13.3.3 currently states: "In order for a compensation handler to be invoked by name, all scopes and activities directly nested in a scope MUST be uniquely named."

Why is the requirement that names be lexically unique buried inside of the compensation section instead of in section 11.1 where activity names are introduced?

Also why does section 11.1 state: "See Flow for a full discussion of these two attributes." (which includes the name attribute)

Although the name attribute is used on a link, link is not an activity and therefore the name attribute as defined in section 11.1 is completely unrelated to the name attribute as used on links.

Which brings up an interesting question - do links have the same naming uniqueness requirements as activities? What about variables or correlation sets? I suspect these are all separate namespaces but is that explicitly stated anywhere in the spec?

Section 13.3.3 also states: "If the value of the scope attribute specified on a compensate activity does not resolve to a unique scope or activity name, the behavior of the process is undefied."

This text would imply that it is acceptable to name an activity other than a scope in the named compensate form <compensate scope="..."/>. Is that implication intended? Also I suspect the last word is supposed to be 'undefined'.
Submitter’s proposal:

Section 13.3.3

Remove the sentence "In order for a compensation handler..."

From: "If the value of the scope attribute specified on a compensate activity does not resolve to a unique scope or activity name, the behavior of the process is undefied."

To: "If the value of the scope attribute specified on a compensate activity does not resolve to a unique scope name in the same scope as the compensate activity then the BPEL MUST be rejected for processing, this requirement MUST be statically enforced."

Section 11.1

From: "See Flow for a full discussion of these two attributes."

To: "See Flow for a full discussion of the suppressJoinFailure attribute. The name attribute is used to provide machine processable names for activities although currently the BPEL specification only makes programmatic use of the names of scope activities. The name of a named activity MUST be unique amongst other named activities used within the same immediately enclosing scope, this requirement MUST be statically enforced."

Section 10.1

From: "Each correlation set is only visible in the scope in which it is defined and in all scopes nested within the scope it belongs to. Thus, global correlation sets are visible throughout the process."

To: "Each correlation set is only visible in the scope in which it is defined and in all scopes nested within the scope it belongs to. Thus, global correlation sets are visible throughout the process. The name of a correlation set MUST be unique amongst the names of other correlation sets defined within the same immediately enclosing scope, this requirement MUST be statically enforced."

Section 12.5

From: "A link has a name and all the links of a flow activity MUST be defined separately within the flow activity."

To: "A link has a name and that name MUST be unique amongst other link names defined within the same immediately enclosing flow, this requirement MUST be statically enforced."

Section 7.2

From: "The name of a partnerLink should be unique within its own scope."

To: "The name of a partnerLink MUST be unique amongst the names of other partnerLinks defined within the same immediately enclosing scope, this requirement MUST be statically enforced."

Section 9.2

From: "The name of a variable should be unique within its own scope."

To: "The name of a variable MUST be unique amongst the names of other variables defined within the same immediately enclosing scope, this requirement MUST be statically enforced."
Changes: 24 May 2005 - 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 - 210 - [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 - 210 - 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).


Choreology Anti virus scan completed


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]