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


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-spec-edit message

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

Subject: Re: [wsbpel] Issue 241 - Proposal for Vote

So I finally got a chance to read the proposal's actual language.  Good job, Alex!

There's one piece of wording that I think it slightly confusing, though, and I'd like to propose that it be removed as an Action Item, since it's not normative in any way.

"Upon receipt of the input message the event handler assigns the input message to the variable before proceeding to perform the event handler activity. Since the variable(s) are declared within a scope associated with the event handler, each instance of the event handler (whether executed serially or concurrently relative to other instances) contains a private copy of the variable(s), which is not shared with other instances. This private copy semantics is further enforced by variable resolution rule: the variable references are resolved to the associated scope only and MUST NOT be resolved to ancestor scopes."

This sentence seems to imply that the activities within the associated scope can't resolve to variables outside the onEvent.  I think that what is trying to be said is that the variable attribute on onEvent resolves to its own implicit declaration.  I can't think of any way of saying that that is readable, and I think it's already been said elsewhere.  Outside of the discussion of the resolution of 242, I don't think that this language is necessary, and the easiest way of dealing with it is to remove the above sentence.


Alex Yiu wrote:

Hi all,

Here is the updated proposal for vote after factoring in Mark Ford's comment about disallowing explicit declaration of variables.

PDF version:

MS Word version:

Here is the highlight of changes in the proposal compared with the one that I sent on Monday:
Variables referenced by variable attribute or <fromPart> element are implicitly declared in the associated scope of <onEvent>. If variable of the same name is declared explicitly in the associated scope, it would be considered a case of duplicated variable declaration and MUST be reported as error during static analysis.

If variable attribute is used in the <onEvent> element, either messageType or element attribute MUST be provided in <onEvent> element. This semantics MUST be enforced during static analysis.

A reminder: one more normative changes we need to make (but not a part of the PDF) is to amend/clarify resolution of Issue 123 in a very minor way as follow:

From: "This resolution follows the same scoping rules as variable and correlationSet resolution."
To: "This resolution follows the same scoping rules as correlationSet resolution."


Alex Yiu

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