[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 event handler
I am. -----Original Message----- From: Assaf Arkin [mailto:arkin@intalio.com] Sent: Friday, October 03, 2003 4:18 PM To: Francisco Curbera Cc: Harvey Reed; Satish Thatte; wsbpel@lists.oasis-open.org; ygoland@bea.com Subject: Re: [wsbpel] Issue 36 - Proposal to vote - Multiple instances of event handler Satish and Edwin, Are you both in favor of option 2? arkin Francisco Curbera wrote: > > >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_wor kgroup >>> >>> > > > >>> >>> >>. >> >> >> >> >>>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_work group. >> >> > > > >>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_work group. >> >> > > > >>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_workg roup.php >. > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]