Re: Issue 120.2 - Proposal For Vote

Part A: (treat as 120.2.1)

Proposal:  

Rescind 204 and change its resolution to no longer require that the
child activity within an <onEvent> be a <scope>. 
Additionally:

onEvent syntax shall be:

<onEvent name="ncname"? partnerLink="ncname"
portType="qname"?

     operation="ncname"  variable="ncname"

         messageExchange="ncname"? >*

             <correlationSets>?

                   <correlationSet name="ncname" 

                      properties="qname-list"/>+

             </correlationSets>

             <correlations>?

        <correlation set="ncname"

            initiate="yes|join|no"?/>+

             </correlations>

             <fromPart part="ncname" toVariable="ncname"/>*

   <!-- added from scope -->

    <partnerLinks>?

     ... see above under <process> for syntax ...

    </partnerLinks>

    <variables>?

     ... see above under <process> for syntax ...

    </variables>

    <faultHandlers>?

     ... see above under <process> for syntax ...

    </faultHandlers>

    <compensationHandler>?

     ... see above under <process> for syntax ...

    </compensationHandler>

    <terminationHandler>?

     ...

    </terminationHandler>

    <eventHandlers>?

      ...

    </eventHandlers>

    <messageExchange>?

    ...

    </messageExchanges>

   <!-- end of things added from scope -->

         activity

    </onEvent>

For the elements that are marked as "added from scope", the syntax and
semantics shall be the same as they are defined in <scope>.  The
syntax and semantics of <messageExchanges> as TBD as defined in
Satish's resolution to Issue 123.  

These elements may be referenced by attributes defined on the
<onEvent>.  I.e.  the partnerLink attribute may refer to a
<partnerLink> element defined inside <partnerLinks>.  The
same holds true for messageExchange, when defined.

For purposes of resolving values
referenced by onEvent attributes, partnerlinks  etc declared in the
onEvent scope come first.   

Rationale:  Semantically, no changes have been made to the
expressibility of the <onEvent> element.  However, syntactically,
we no longer have to deal with definining the variable and
messageExchange in a way that is different from how it is defined
elsewhere, and possible "forward" referencing.  (We trade "lateral
referencing" for "forward referencing" - which isn't actually forward,
it's "downward")  Nor do we have to deal with the anomaly of an onEvent
requiring a scope to be its child.

The onEvent now has all of the elements and attributes of <scope>
except:  suppressJoinFailure and standard-elements.  They make no
sense, as they deal with links, which are disallowed to and from
<onEvent>.  I left off "isolated" because I didn't think it was
relevant.  I'm open to discussion on this.

----------------------

If part A looks good to
folks,
then parts B and C can have verbiage added..  I decided not to take the
time, since
I think it's fairly obvious, and the intent here is to show people
where my though processes are going with 120.2  Note that A can happen
independently of B or C.

Part B:  (treat as 120.2.2)

Rescind 204 completely.  Add the elements and attributes from scope
(except suppressJoinFalure, isolated, and standard-elements for
onAlarm) that are not currently on <onAlarm> and <forEach>

Rationale:  Extend the relevant rationale from Part A

NOTE: This proposal probably depends on part A passing, but doesn't
require part C.

--------------------

Part C:  (treat as 120.2.3)

Rescind 147.4  Re-resolve the other way:  I.e. separate activities for
serial and parallel forEach.  Part B would only apply to
parellelForEach if B is accepted as well.

Rationale:  Serial and parallel forEach are semantically divergent.  They are getting more and more divergent
syntactically.  Cf.  204, 6.2, 216, 120.2.2, 227, and probably others. 
It is to the point where it is easier to make them different and point
out the similarities, than it is to keep them the same and point out
the differences.

NOTE:  This is not dependent on either part A or part B.

Danny van der Rijn wrote:
 As
discussed at the F2F this morning, here are my thoughts for solving
120.2, although I need to think some more before I want this to come up
for vote.

  

  To take all of the attributes
and
elements that we care about (tbd later) from scope and put them on
onevent.
   

  

  Allow partner links and, when
introduced,
message exchange attribute declarations to be declared inside the
onevent
element, to be referenced by attributes used by onevent.     

  

  For purposes of resolving
values
referenced by onevent attributes, partnerlinks  etc declared in the
onevent scope come first.