Re: [wsbpel] Issue 147 - Proposal For Vote

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

 > -1 to the notion of spelling out the "returned set" and removing
 > elements from it.  Why specify to such detail how the iterator works?

Can you please explain how it is possible to portably define for-each 
without specifying this behavior?

 > -1 to the above paragraph.

Um... o.k. Would you like to explain why? And how you would replace it 
and still have for-each work efficiently?

 > All this talk of references/aliases is going to expand the scope of the
 > spec.  I'm sure you have a proposal in the wings, but why not alias
 > variables?

I think that introducing a generic mechanism to alias variables would 
expand the scope of the spec and not necessarily in a way useful enough 
to be justified for a 1.0 spec (no matter what we named the silly 
thing). On the other hand what is proposed in for-each is a very limited 
mechanism that exactly replicates the behavior of two processes 
manipulating the same variable.

	Yaron

Danny van der Rijn wrote:
> 
> Yaron Y. Goland wrote:
> 
>  > 147 - Serial and Parallel For-Each
>  >
>  > Proposal: Introduce a foreach to BPEL with both serial and parallel
>  > semantics.
>  >
>  > Rationale: Just check the issue list for issue 147. There is a whole
>  > series of mails attesting to how important this activity is.
>  >
>  > Introduce a section 12.6
>  >
>  > Note: This proposal assumes that issue 126 is adopted.
>  >
>  > 12.6 - Foreach
>  >
>  > <foreach iteratorVariableName="ncname" iteratorVariableType="qname"\
>  >            parallel="xs:Boolean" validate="yes|no"? standard-attributes>
>  >      standard-elements
>  >      <expression expressionLanguage="anyURI">...</query>
>  >      activity
>  > </foreach>
>  >
>  > A foreach activity is used to iterate over a variable, either serially
>  > or in parallel. The foreach activity specifies an expression that is
>  > to return a set of element information items (EIIs). The foreach also
>  > specifies a variable name in the iteratorVariableName attribute and a
>  > variable type in the iteratorVariableType attribute. All the EIIs
>  > returned by the expression MUST be of the type specified by the
>  > variable type. By default however a BPEL engine is not required to
>  > validate variable types, if the programmer wishes to guarantee that
>  > the output of the expression will be validated to be of the
>  > appropriate type then the validate attribute should be set to 'yes'.
>  > If the validate attribute is set to 'yes' and the output of the
>  > expression are not all EIIs of the type specified by
>  > iteratorVariableType then a mismatchedAssignment failure MUST be
>  > thrown. Note that variable validation, if activated, is performed
>  > before any of the 'notional' virtual scopes described below are created.
>  >
>  > If parallel="no" then the foreach is a serial foreach. In that case,
>  > conceptually, a new 'notional' virtual scope is created that does not
>  > contain a fault handler nor a compensation handler. In fact, this
>  > 'notional' virtual scope cannot be said to exist for purposes of
>  > determining which scopes are children of other scopes. Please refer to
>  > section 13.5.1 for a full description of the compensation handle of
>  > this 'notional' virtual scope. This 'notional' virtual scope contains
>  > a single variable declaration with the name given in
>  > iteratorVariableName and the type given in iteratorVariableType. The
>  > virtual scope conceptually contains a virtual sequence. The first
>  > entry in the sequence is an assign that assigns an EII from the
>  > returned set, in document order where possible, in random order where
>  > not, to the scope's only variable. Once an EII from the return set is
>  > assigned to the local variable that EII is removed from the return
>  > set. The next activity in the sequence is then the activity specified
>  > in the body of the foreach activity. If the virtual scope exits
>  > without error and if there are remaining EIIs in the returned set then
>  > the process repeats until the returned set is empty.
> 
> 
> -1 to the notion of spelling out the "returned set" and removing
> elements from it.  Why specify to such detail how the iterator works?
> 
>  >
>  > The EIIs in the returned set are aliases to real EII instances held in
>  > BPEL variables. It is possible for one of the EIIs being pointed to,
>  > to be deleted while the for-each is executing. Such a deletion would
>  > occur if the EII being pointed to was removed from the BPEL variable
>  > that contained it. In that case the EII disappears from the returned
>  > set and is not iterated over.
> 
> 
> -1 to the above paragraph.
> 
>  >
>  > The foreach virtual scope local variable in the foreach iteration
>  > instance is also an alias to an actual EII in a BPEL variable. While
>  > the iteration instance is executing the EII could have its value
>  > changed. If that happens then the situation is similar to what happens
>  > if a BPEL variable is shared by two simultaneously executing sections
>  > of a BPEL, the change made in one section is instantly visible to the
>  > other. If, however, the EII instance is deleted then the virtual scope
>  > local variable will become null. It is legal to assign to the virtual
>  > scope local variable after it becomes null but the value will be lost
>  > when that iteration ends, just as with any other scope local variable.
>  > To prevent other parts of a BPEL from altering the return set or the
>  > scope local variable the foreach can be placed in a serialized scope.
> 
> 
> All this talk of references/aliases is going to expand the scope of the
> spec.  I'm sure you have a proposal in the wings, but why not alias
> variables?
> 
>  >
>  > If the parallel attribute is set to 'yes' then a parallel foreach is
>  > created. In a parallel foreach a virtual flow is created that contains
>  > a series of virtual scopes, one for each EII in the returned value
>  > set, defined as given previously. As with a serial foreach the local
>  > variables in the parallel scopes are aliases to actual BPEL values
>  > with the same behavior as given above. While the possibility of
>  > interference can be reduced by placing a parallel foreach into a
>  > serialized scope this cannot prevent parallel virtual scopes generated
>  > by the foreach from interfering with each other since they all exist
>  > inside of the same serialized scope. A parallel foreach ends using the
>  > same logic that controls any flow's behavior. That is, either all the
>  > scopes in the flow successfully exit or one of the scopes throws an
>  > unhandled fault and the flow is terminated.
>  >
>  > Addition to Appendix A:
>  >
>  > mismatchedAssignment  Thrown from a for-each if the returned iterator
>  > set is validated and contains entries of a type other than that
>  > specified in iteratorVariableType.
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>  > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>  >
>  >
>