Issue - 270 - Proposal to vote

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

Resending my proposal with new subject and slightly different wording based on feedback from Alex during call. There was general agreement on supporting this proposal but some concern over how to phrase the copy of a partially initialized message variable.

 

Section 8.4.2:

---- from ----

Replacement Logic for WSDL Message Variables

When the from-spec and to-spec of a <copy> operation both select WSDL message variables, the value of the from-spec message variable MUST be copied, becoming the value of the to-spec message variable. The original message parts of the to-spec message variable will not be available after the <copy> operation.

---- to ----

Replacement Logic for WSDL Message Variables

When the from-spec and to-spec of a <copy> operation both select WSDL message variables, the value of the from-spec message variable MUST be copied, becoming the value of the to-spec message variable.  If the from-spec message variable is partially initialized then any uninitialized parts of the from-spec message variable result in the same uninitialized parts for the to-spec variable. The original message parts of the to-spec message variable will not be available after the <copy> operation.

---- end ----

Lastly, I think we should also disallow the use of a partially initialized message variable with a <throw>. This seems consistent with the resolution of Issue 258 which disallowed the use of such a variable with <invoke> or <reply>. The change there would be to add the <throw> to the end of Section 8.1 where the resolution text for Issue 258 was added.

---- from ----

An attempt during process execution to read a variable or, in the case of a message type variable, a part of a variable before it is initialized MUST result in the standard bpel:uninitializedVariable fault. This includes the <invoke> and <reply> activity, where the presence of an uninitialized part also results in the standard fault bpel:uninitializedVariable.

---- to ----

An attempt during process execution to read a variable or, in the case of a message type variable, a part of a variable before it is initialized MUST result in the standard bpel:uninitializedVariable fault. This includes the <invoke>, <reply>, and <throw> activities, where the presence of an uninitialized part also results in the standard fault bpel:uninitializedVariable.

---- end ----