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] Issue 36 - Proposal to vote - Multiple instances of eventhandler






If you guys are deciding what option to present to the group for voting, I
would really appreciate if you selected option 2 ;-).

Paco



                                                                                                                                  
                      Assaf Arkin                                                                                                 
                      <arkin@intalio.co        To:       Harvey Reed <hreed@sonicsoftware.com>                                    
                      m>                       cc:       ygoland@bea.com, "'Satish Thatte'" <satisht@microsoft.com>,              
                                                wsbpel@lists.oasis-open.org                                                       
                      10/02/2003 03:38         Subject:  Re: [wsbpel] Issue 36 - Proposal to vote - Multiple instances of event   
                      PM                        handler                                                                           
                                                                                                                                  




Harvey Reed wrote:

>The thematic approach is for the champion to work the issue out in threads
>(like what is happening here), then present a proposal. In this case the
>champion is a small group. Then the motion is to accept or reject. If
there
>are alternatives then it's still to early to present a proposal.
>
So if I understand it correctly, we narrowed it down to a list of two
options, Satish presented the pros & cons of either one, so far Satish,
Edwin and myself are the only ones expressing any opinion in favor of
one or the other, which implies that we are the only one interested in
which particular options it ends up being. The group would find it
easier if we just narrow it down and present a single option. Is that
correct?

In that case I don't see a problem with us presenting a single option
for the group to vote on.

arkin

>++Harvey
>
>
>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com]
>Sent: Thursday, October 02, 2003 3:22 PM
>To: ygoland@bea.com
>Cc: 'Satish Thatte'; wsbpel@lists.oasis-open.org
>Subject: Re: [wsbpel] Issue 36 - Proposal to vote - Multiple instances of
>event handler
>
>The reason we have two options is to not make two separate issues out of
>it, but fold them into one, while at the same time presenting two
>alternatives. I do agree that having one option would make the voting
>simpler, but I also got the impression that people want to discuss this
>during the conf call. Perhaps we could fold it into one option during
>the conf call if there's no strong feeling either way.
>
>If it does boil down to only Satish, Edwin and myself having any
>opinion, then I guess we could decide now and present only one option
>during the conf call. But does that give the group enough info into the
>alternatives?
>
>The question is, does anyone else have an opinion in favor of a
>particular option, or do people just want one option to vote on?
>
>arkin
>
>
>Yaron Goland wrote:
>
>
>
>>On a procedural note motions are typically 'yes or no' not multiple
choice
>>because multiple choices leads to confusion. Could the parties involved
>>possibly come to an internal consensus and just put up a single option to
>>
>>
>be
>
>
>>voted on?
>>
>>My apathy as to which choice to pick is such that I don't have strong
>>feelings either way. But it seems both Edwin and Satish want option 2. So
>>why not just pick that one for the motion?
>>
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: Satish Thatte [mailto:satisht@microsoft.com]
>>>Sent: Tuesday, September 30, 2003 10:42 PM
>>>To: Assaf Arkin; wsbpel@lists.oasis-open.org
>>>Subject: RE: [wsbpel] Issue 36 - Proposal to vote - Multiple instances
>>>of event handler
>>>
>>>
>>>My 2 cents on the options.
>>>
>>>The advantage of Assaf's option 1 is minimality and consistency with
>>>"pick".
>>>
>>>The disadvantage is that we now have a variable declaration where the
>>>type is specified externally.
>>>
>>>Related issue regarding broken catch syntax (issue 68) will raise this
>>>problem again: when the fault name is missing the type must be
>>>specified.
>>>
>>>I prefer the regularity of always declaring the type when you
>>>declare a
>>>variable, whether within <variables> or catch handlers or event
>>>handlers.
>>>
>>>An advantage of option 2 is redundancy that is an aid to static
>>>checking, along the same lines as the createInstance attribute on an
>>>initial receive.
>>>
>>>Satish
>>>
>>>-----Original Message-----
>>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>>Sent: Tuesday, September 30, 2003 7:51 PM
>>>To: wsbpel@lists.oasis-open.org
>>>Subject: [wsbpel] Issue 36 - Proposal to vote - Multiple instances of
>>>event handler
>>>
>>>Proposal to resolve issue 36.
>>>
>>>The semantics of event handler would be changed to allow the variable
>>>used to capture the input message to be treated local to the event
>>>handler instance:
>>>
>>>1. The name of the variable is given in the variable attribute.
>>>
>>>2. The variable type must be the same as the type of the input message
>>>defined by referenced operation.
>>>
>>>3. The event handler declares a variable of that name and type that is
>>>scoped to the event handler activity.
>>>
>>>4. Upon receipt of the input message the event handler
>>>assigns the input
>>>message to the variable before proceeding to perform the event handler
>>>activity.
>>>
>>>5. Since the variable is scoped to that activity, two instances of the
>>>activity (whether executed seriallly or
>>>concurrently) do not operate on the same variable.
>>>
>>>From that base proposal we have to options that we should vote on:
>>>
>>>Option 1:
>>>
>>>1. Retain the element name onMessage
>>>
>>>2. The variable type is derived from the message type used as input by
>>>the referenced operation
>>>
>>>Option 2:
>>>
>>>1. Rename eventHandler/onMessage to eventHandler/onEvent
>>>
>>>2. The attribute messageType specifies the variable type by
>>>referencing
>>>the message type definition using its QName.
>>>
>>>arkin
>>>
>>>
>>>
>>>
>>>
>>>
>>>To unsubscribe from this mailing list (and be removed from
>>>the roster of
>>>the OASIS TC), go to
>>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
>>>
>>>
>>>
>>>
>>ave_workgr
>>oup.php.
>>
>>
>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster of
>>
>>
>the
>
>
>>OASIS TC), go to
>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup

>>
>>
>.
>
>
>>php.
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>To unsubscribe from this mailing list (and be removed from the roster of
>>
>>
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.

>php.
>
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.

>php.
>
>
>



To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.





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