[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
Although I am tempted to point out that one could see some use cases where one would want to be able to omit the variable attribute on both onMessage and onEvent (e.g. the code doesn't actually care about the content of the message/event, just that it happened). But that sounds like a normative change to me. 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]