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


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.

++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.




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