[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]