[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel-spec-edit] more discrepancies in specs and XSD
|
Hi, IIRC the spec originally had the "variable" attribute as optional on both OnEvent (renamed from original "onMessage EventHanlder" ) as well the onMessage clause in the Pick activity. However based on an issue that was raised with the use of the same variable in multiple concurrent OnEvent handlers that may come into existence, we defined the variable on OnEvent handlers to be local to the EventHandler and made it mandatory (see section 13.5.1) "The variable attribute identifies a variable local to the eventHandler that will contain the message received from the partner. The messageType attribute specifies the type of the variable by referencing a message type definition using its QName. The type of the variable (as specified by the messageType attribute) must be the same as the type of the input message defined by operation referenced by the operation attribute. The variable and messageType attributes constitute the declaration of a variable of that name and type within an implicit scope associated with the event handler. Upon receipt of the input message the event handler assigns the input message to the variable before proceeding to perform the event handler activity. Since the variable is declared within a scope associated with the event handler, each instance of the event handler (whether executed serially or concurrently relative to other instances) contains a private copy of the variable, which is not shared with other instances. This did not change the semantics of the OnMessage clause in Pick, which is defined to have same semantics as receive. Hence the variable there is still optional. The text below in 13.5.1 that speaks to optional nature of variable on OnEvent handler is incorrect, essentially leftover and not fixed with the change that change that renamed onMessage EventHandler to OnEvent. "The semantics of the onEvent event is identical to a receive activity regarding the _*optional nature of the variable attribute*_, the handling of race conditions, and the constraint regarding simultaneous enablement of conflicting receive actions."The above paragraph needs to be fixed up to reflect the mandatory nature of variable attribute in OnEvent handler however. Regards, Prasad -------- Original Message --------
Given that the current text (based on your reading) doesn't say that the variable used in onMessage should be optional we can treat this as a typo and make it mandatory. Alex Yiu wrote: > Hi, All, > > Besides the discrepanies discovered by Dieter, there are others that I would > like to mention and have clarification questions to ask. > > *[A]* > I would like to get some clarification regarding to the current status of the > spec. (These questions are discovered when I am trying to fix errors in the XSD) > > In <onMessage> variable is optional > > <onMessage partnerLink="ncname" portType="qname"? > operation="ncname" variable="ncname"?>+ > > I cannot find related text for onMessage to describe the optional nature of > variable attribute. > > In <onEvent> variable is required: > > <onEvent partnerLink="ncname" portType="qname"? > operation="ncname" messageType="qname" > variable="ncname">* > > > ==> Is this difference/discrepancy here truely intended? (not a typo mistake?) > > Please also note that in the text for <onEvent>, it mentioned optional nature of > the variable attribute. > > ==> There is another discrepancy. > > Text from Section "13.5.1. Message Events": > "The semantics of the onEvent event is identical to a receive activity regarding > the _*optional nature of the variable attribute*_, the handling of race > conditions, and the constraint regarding simultaneous enablement of conflicting > receive actions." > > > *[B]* > As mentioned before, the following mistake was discovered in the main spec a > month ago. It is a trivial fix, which I do it this week when I am holding the pen. > > ======================== > <targets>? > <target linkName="ncname">+ > <joinCondition expressionLanguage="anyURI"?>? > ... bool-expr ... > </joinCondition> > </target> > </targets> > <sources>? > <source linkName="ncname">+ > <transitionCondition expressionLanguage="anyURI"?>? > ... bool-expr ... > </transitionCondition> > </source> > </sources> > ======================== > > It is not in sync with the rest of the spec. > > I guess it should become: > ======================== > <targets>? > * <joinCondition expressionLanguage="anyURI"?>? > ... bool-expr ... > </joinCondition> > ** <target linkName="ncname"/>+* > </targets> > <sources>? > <source linkName="ncname">+ > <transitionCondition expressionLanguage="anyURI"?>? > ... bool-expr ... > </transitionCondition> > </source> > </sources> > ======================== > > > Thanks! > > > > Regards, > Alex Yiu > > > > Alex Yiu wrote: > >> >> FYI ... some old mistakes discovered in the schema. >> >> -------- Original Message -------- >> Subject: Re: BPEL XML Schema >> Date: Thu, 23 Sep 2004 19:14:03 +0200 >> From: Dieter Koenig1 <dieterkoenig@de.ibm.com> >> To: Alex Yiu <alex.yiu@oracle.com> >> CC: Alex Yiu <alex.yiu@oracle.com>, Francisco Curbera <curbera@us.ibm.com>, >> Rania Khalaf <rkhalaf@us.ibm.com>, Satish Thatte <satisht@microsoft.com> >> >> >> >> >>Great, thanks!! >>Kind Regards >>DK >> >> >> >> >> Alex Yiu >> <alex.yiu@oracle. >> com> To >> Dieter Koenig1/Germany/IBM@IBMDE >> 23.09.2004 18:56 cc >> Francisco Curbera >> <curbera@us.ibm.com>, Rania Khalaf >> <rkhalaf@us.ibm.com>, Satish Thatte >> <satisht@microsoft.com>, Alex Yiu >> <alex.yiu@oracle.com> >> Subject >> Re: BPEL XML Schema >> >> >> >>Hi, Dieter, >> >>Thanks for discovering these issues in the schema. >>I concur all of your findings. >> >>Those issues have been hidden inside the schema for a while. It sure >>feels good to kill those bugs in schema. :-) >> >>One technical note: for item (5), I will use schema extension to fix >>this problem. tOnEvent will extend from tOnMessage. >> >>Thanks!!! >> >> >>Regards, >>Alex Yiu >> >> >> >>Dieter Koenig1 wrote: >> >>> >>> >>>Hi Alex, there are a couple of places where the XML schema is not yet >>fully >>>"compliant" with the specification. Please consider the following for one >>>of the next XML schema versions: >>> >>> 1) In tProcess, element tImport may occur more than once --> add >>>maxoccurs="unbounded" >>> 2) In tImport, all attributes are required --> add use="required" (3x) >>> >>> 3) In tTargets, element joinCondition must be optional --> add >>>minOccurs="0" >>> 4) In tSource, element transitionsCondition must be optional --> add >>>minOccurs="0" >>> >>> 5) In tEventhandlers, element onEvent is defined with type tOnMessage >>> In tPick, element onMessage is defined with type tOnMessage as well >>> In tOnMessage, a new required attribute messageType has been >>introduced >>> However, messageType is only needed for onEvent, but not for onMessage >>> --> >>> Introduce new type tOnEvent with attribute messageType >>> Define element onEvent with the new type tOnEvent >>> In tOnMessage, delete attribute messageType >>> >>>Kind Regards >>>DK |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]