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 <>
>> To: Alex Yiu <>
>> CC: Alex Yiu <>, Francisco Curbera <>,
>> Rania Khalaf <>, Satish Thatte <>
>>
>>
>>
>>
>>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
>> <>, Rania Khalaf
>> <>, Satish Thatte
>> <>, Alex Yiu
>> <>
>> 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
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
