[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 297 -Proposal For Vote
Hi Alex,
My goal was to avoid
possible user error of having different queries for messageType and element
property aliases but that seems difficult to accomplish. As you pointed out,
comparing two <bpel:query> elements could be difficult if the queries
differ in insignificant ways (whitespace, braces, comments ...etc).
What do you think of
adding a requirement that if these two aliases exist then their queries SHOULD
produce the same result? This way, the query language or syntax could differ
between aliases. The only requirement is that they produce the same result.
Perhaps a MUST would be better here?
Here's another attempt at
this:
Section 9.2
--- 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:
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 ---
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. From: Alex Yiu
[mailto:alex.yiu@oracle.com]
Sent: Tuesday, June 20, 2006 3:50 PM 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 taking first stab to add this constraint into spec language. Few quick notes:
Here is my suggestiond revision to the proposal: ================================ --- 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
element based propertyAlias match the
message,
then the messageType based
<propertyAlias> MUST take priority, while both
<propertyAlias> should 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 messageType and another element-based property alias is defined for the same
property QName and element QName is same as the
message part then these two property aliases SHOULD
have identical queries. This constraint SHOULD be enforced by static
analysis.
================================ What do you think? Thanks! Regards, Alex Yiu Mark Ford wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]