Hi Assaf,
My preference would be option #2. Have a good week end!
Edwin
> -----Original Message-----
> From: Assaf Arkin [mailto:]
> Sent: Friday, October 03, 2003 4:18 PM
> To: Francisco Curbera
> Cc: Harvey Reed; 'Satish Thatte';
> ;
> 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
>
> > < To:
> Harvey Reed <>
>
> > m> cc:
> , "'Satish Thatte'" <>,
>
> >
>
>
> > 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:]
> >>Sent: Thursday, October 02, 2003 3:22 PM
> >>To:
> >>Cc: 'Satish Thatte';
> >>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:]
> >>>>Sent: Tuesday, September 30, 2003 10:42 PM
> >>>>To: Assaf Arkin;
> >>>>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:]
> >>>>Sent: Tuesday, September 30, 2003 7:51 PM
> >>>>To:
> >>>>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_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/l
eave_workg
> >roup.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/le
ave_workgroup.php.
>
>
