Issue 297 Proposal to vote

["Mark Ford" <mark.ford@active-endpoints.com>]

Title: Issue 297 Proposal to vote

This is an updated proposal that incorporates changes from the June 21 call. Please note that this is no longer a two part proposal. I have decided to drop the second part since it ended up being a "best practice" tip and this doesn't seem like something we should be adding at this stage.

Formal Proposal

(Change to Section 9.2)

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;

or
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. A type based <propertyAlias> is never considered for retrieving correlation values. These matching rules apply only to retrieving correlation values and have no effect on selecting a <propertyAlias> for use in a from-spec, to-spec, or bpel:getVariableProperty.

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.