[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 297 - Proposal to Vote
You introduce/change the following rules in this proposal: A. "If both a messageType and element based propertyAlias match the message, then the messageType based <propertyAlias> MUST take priority." B. "If a property alias is defined for a single element part messageType and another element-based property alias is defined for the same property QName and same element QName as the message part, then the queries for these two property aliases SHOULD produce the same result." IMO, rule A. is the right direction. It resolves conflicts if multiple property aliases are present. Questions: - Q1: In both rules, what about property aliases with the *type* attribute? - Q2: Is rule B. required at all? In other words, why do we care when according to rule A., all non-messageType-based property aliases are ignored? Kind Regards DK Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220 Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany "Mark Ford" <mark.ford@active -endpoints.com> To <wsbpel@lists.oasis-open.org> 21.06.2006 01:21 cc "'Alex Yiu'" <alex.yiu@oracle.com>, Thomas Schulze/Germany/IBM@IBMDE, Dieter Koenig1/Germany/IBM@IBMDE Subject [wsbpel] Issue - 297 - Proposal to Vote This is the final text that Alex and I agreed on. I think it makes the rules for resolving the property alias clear. It also addresses the issue of having different queries for an element based alias and a messageType alias for the same property. Change Section 9.2 --- from --- Observe that in order to retrieve correlation values from a message, a processor needs to apply a particular <propertyAlias> to the message. In the case in which the application of the <propertyAlias> results in a response that contains anything other than exactly one information item and/or a collection of Character Information Items then a bpel:selectionFailure fault MUST be thrown. --- to --- Observe that in order to retrieve correlation values from a message, a processor MUST find a matching <propertyAlias> and apply it to the message. A <propertyAlias> is considered matching with a message if: 1. the messageType attribute value used in <propertyAlias> definition matches the QName of the WSDL message type associated with the message; 2. the message is associated with a WSDL message type where the message contains a single part defined by an element and the element attribute value used in <propertyAlias> definition matches the QName of the element used to define the WSDL part This matching <propertyAlias> constraint MUST be statically enforced. If both a messageType and element based propertyAlias match the message, then the messageType based <propertyAlias> MUST take priority. In the case in which the application of the <propertyAlias> results in a response that contains anything other than exactly one information item and/or a collection of Character Information Items then a bpel:selectionFailure fault MUST be thrown. --- end --- Change Section 7.3 --- from --- A WS-BPEL process definition MUST NOT be accepted for processing if it defines two or more property aliases for the same property name and WS-BPEL variable type. For example, it is not legal to define two property aliases for the property tns:taxpayerNumber and the messageType txmsg:taxpayerInfoMsg. The same logic would prohibit having two property aliases on the same element QName and property name value or two property aliases on the same type QName and property name value. --- to --- A WS-BPEL process definition MUST NOT be accepted for processing if it defines two or more property aliases for the same property name and WS-BPEL variable type. For example, it is not legal to define two property aliases for the property tns:taxpayerNumber and the messageType txmsg:taxpayerInfoMsg. The same logic would prohibit having two property aliases on the same element QName and property name value or two property aliases on the same type QName and property name value. If a property alias is defined for a single element part messageType and another element-based property alias is defined for the same property QName and same element QName as the message part, then the queries for these two property aliases SHOULD produce the same result.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]