[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 297 -Proposal For Vote
If we introduce a
requirement that the messageType and elementType propertyAliases must have
identical queries then we don't need to state which one takes priority if both
match. My changes are in bold below:
--- begin
---
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:
This matching <propertyAlias> constraint MUST be
statically enforced. If both a messageType and
elementType propertyAlias match the message, then either can be used to
retrieve the correlation values as they are required to have identical queries
(See Section 7.3). 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 ---
The above change
requires a change in Section 7.3 to
include this restriction.
--- 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 message and another property
alias is defined for the same property QName and element QName as the message
part then these two property aliases MUST have identical queries. This
constraint MUST be enforced by static analysis.
From: Alex Yiu [mailto:alex.yiu@oracle.com] Sent: Monday, June 19, 2006 4:44 AM To: Mark Ford Cc: wsbpel@lists.oasis-open.org; 'Thomas Schulze'; 'Dieter Koenig1'; Alex Yiu Subject: Re: [wsbpel] Issue - 297 -Proposal For Vote Hi Mark, Thank you for agreeing that <catch> style rules make sense here. Fortunately, <propertyAlias> has fewer knobs than in <catch>. So, its matching rules are much simplier. Proposal For Vote: ============================ In Section 9.2, change --- 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 to the message. A
<propertyAlias> is considered matching with a message if:
This matching
<propertyAlias> constraint MUST be statically enforced. When more than one <propertyAlias> definitions are matched
with a message, 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. ============================The green parts are based on your original proposal (with some minor rewording). The blue parts are added to handle element-based propertyAlias matching. They are consistent with the <catch> matching rules defined in section 12.5 (particularly rule #2/#5 there). I guess this proposal is good because of its consistency with <catch> rules and it is simple enough to avoid any introducing any new bugs. [After this proposal is passed, we may want to loop back to Issue 280 and wrap it up.] Thanks! Regards, Alex Yiu Mark Ford wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]