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.
Comments?
Alex Yiu wrote:
Hi all,
[A]
Here is the updated proposal for vote after factoring in Mark Ford's
comment about disallowing explicit declaration of variables.
PDF version:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/17037/wsbpel-specification-draft.241_proposal_v3.pdf
MS Word version:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/17036/wsbpel-specification-draft.241_proposal_v3.doc
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.
------------------------
[B]
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."
Thanks!
Regards,
Alex Yiu
|