Re: [wsbpel-spec-edit] Re: [wsbpel] Issue 241 - Proposal for Vote

Sounds good to me.  Thanks!

Danny

Alex Yiu wrote:

  
  

Danny,

  

Thanks for your compliment. :-) 

  

I understand and agree with your concern of potential confusion. 

  

On the other hand, the rule about variable references of
<onEvent> "MUST NOT be
resolved
to ancestor scopes" is not explicitly stated in
other places of the spec/proposal, even though it is implied by other
parts spec. [ And, I do not exactly like guessing-implication-game in
spec text ;-) ]

  

And, this potential
confusion actually still exists in old spec text, even after we remove
that new sentence. 

  

  Hence, I
tend
to prefer re-phrasing it, rather than removing it. How about: 

  

  
  Upon
receipt of the inbound message the
event
handler assigns the inbound message
to the variable(s) before proceeding to
perform the event handler activity. Since the variable(s) for inbound message
of <onEvent> are implicitly 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 those variable(s),
which is not shared with other
instances. This private copy semantics also
implies that variable references used
for inbound message of <onEvent>
are resolved to the associated scope only and MUST NOT be
resolved
to ancestor scopes
    

  
  

Now most of appearances of "variable" are now qualified with "for
inbound message of <onEvent>" in this paragraph. I guess it will
decrease the chance of confusion. 

  

And, "private copy" semantics of general variables are covered in
section 12.5.7 "Concurrency Consideration" which is covered under Issue
245. 

  

  

What do you think? 

  

  

Thanks!

  

  

Regards,

Alex Yiu

  

  

Danny van der Rijn wrote:
  
    
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