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: Re: [wsbpel] Re: Issue 120.2 - Proposal For Vote


You make a good point, Alexandre.  When the formal proposal comes up again, I'll make sure it has "isolated" in it.

Danny

Alexandre Alves wrote:

Hi Danny,

 

“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.”

 

I think we should keep the ‘isolated’ attribute. <onEvent> are always in the context of concurrency, so it would be helpful to be able to synchronize the <onEvent> as a unit, instead each of its nested activity (e.g. sequence, flow) and declarations (e.g. fault handlers, compensation handlers, etc)… Before it was not such a big deal, as there could only be nested activity, but no nested declarations.

 

Regards,

Alexandre

 


From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Friday, September 30, 2005 2:24 PM
To: wsbpeltc
Subject: [wsbpel] 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.  

 

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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