Issue 132 - Proposal For Vote

["Yaron Y. Goland" <ygoland@bea.com>]

Note: This text includes the complete list of changes discussed at the 
F2F. This includes the changes Ivana made in her friendly amendment 
along with a number of others that were also discussed.

132 - In-line Variable Initialization

Proposal: Allow in-line variable initialization in BPEL

Rationale: Many languages allow for variables to be initialized when 
they are declared so as to allow for an explicit relationship between 
the variable and its initial value. That way no one can accidentally 
insert code between the variable and its initialization thus causing 
various unforeseen problems.

Changes Required:

Section 9.2. Variable

Change the variable syntax declaration to:
<variables>
	<variable name="ncname" messageType="qname"?
		type=”qname”? element=”qname”?>+
                         from-spec?
             </variable>
</variables>

Insert the following paragraph after the paragraph that ends "However 
the children of the document element MUST exclusively consist of the 
complexType values assigned to the variable.":

A variable can optionally be initialized by using an in-line from-spec. 
From-spec is defined in section 9.3. Conceptually the in-line variable 
initializations are modeled as a virtual sequence activity that contains 
a series of virtual assign activities, one for each variable being 
initialized in the order they are listed in the variable declarations. 
The virtual assigns then each contain a single virtual copy whose 
from-spec is as given in the variable initialization and the to-spec 
points to the variable being created. The previous discussion of virtual 
sequences and assigns is only meant for modeling purposes. The 
description is strictly intended to describe initialization behavior in 
terms of previously understood concepts but there is no intention that 
the behavior be seen as actually implying that any of the 'virtual' 
sequences or assigns exist as anything other than a model of the 
expected behavior.

Variable initialization logic contained in scopes that contain or whose 
progeny contain a start activity MUST only use idempotent functions. The 
use of idempotent functions allows for all the values for such variables 
to be pre-computed and re-used on each process instance.

Section 13:

Insert the following text after the sentence "The scope is shared by all 
the nested activities.":

When a process/scope is entered scope initialization occurs. Scope 
initialization consists of instantiating the scope's fault handlers, 
termination handlers, partner links, correlation sets and variables, 
including variable initializations. Any partner links defined in the 
scope MUST be created before variables defined in the same scope whose 
initialization logic refers to those partner links. Scope initialization 
is an all or nothing behavior, either it all occurs successfully or a 
bpws:scopeInitializationFailure fault is thrown which MUST be caught by 
the parent scope of the failed scope. In the case of a failure at the 
process level the entire process is treated as faulted. Once scope 
initialization completes the main activity of the scope and the scope's 
event handlers are instantiated in parallel with each other. An 
exception to the previous rule applies to scopes that contain a 
process's initial start activity. An initial start activity is the start 
activity that caused a particular process instance to be instantiated. 
If a scope contains an initial start activity then the start activity 
MUST complete before the event handlers are instantiated.

Addition to Appendix A:

bpws:scopeInitializationFailure  Thrown if there is any problem creating 
any of the objects defined as part of scope initialization. This fault 
is always caught by the parent scope of the faulted scope.

Change Schema for tVariable to:

<complexType name="tVariable">
   <complexContent>
       <extension base="bpws:tExtensibleElements">
          <sequence>
             <element ref="bpws:from" minOccurs="0"/>
          </sequence>
          <attribute name="name" type="NCName" use="required"/>
          <attribute name="messageType" type="QName" use="optional"/>
          <attribute name="type" type="QName" use="optional"/>
          <attribute name="element" type="QName" use="optional"/>
       </extension>
    </complexContent>	
</complexType>