Re: [wsbpel] RE: Issue 147 - some comemnts and questions

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

> A) validate=true - I think this is good, however I would not start to
> introduce this attribute with for-each. I would expect a validation-hint
> to be added globally in bpel or no where (i.e. only as vendor
> extensions). I am not sure we have it already somewhere?
> 

In issue 160 we passed an explicit validation switch to be used with 
assign. The 147 proposal follows the same design.

> Design issues:
> 
> B) "removed from result set" I agree with Danny that this is a
> implementation detail (actually a confusing one, especially in
> combination with allowing for changes in the set). I would prefer
> something like "the engine ensures to execute the virtual scope for each
> EII in the result set (at the time the for-each was activated) exactly
> once". This is imho a portable definition and less complicated.
> 

Imagine that a serial for-each expression generates 4 results.

While the first iteration of the for-each is being processed a parallel 
part of the BPEL flow edits the variable that the results were generated 
from and deletes the remaining 3 values.

If we use the semantics suggested above then the for-each would continue 
to iterate 3 more times, even though the values being iterated on no 
longer exist. The result is that the iterator value in all three 
remaining iterations would be uninitialized.

I believe such behavior to be counter intuitive.

> C) iteratorVariable - I have experiences with a similiar construct,
> which however works as an integer counter instead of an iterator. This
> has the DISadvantage, that it is less "object oriented", however it has
> the advantage that it is reuseable. I get the position of the EII as an
> index and can address it with an assign (in the case of XPAth:
> /somewhere/resultnode[$intInter}).
> 
> Especiually I can use this integer also for another variable where i
> want to accumulate the results (asuming some defined order of the EII
> however)
> 
> For-each query="$in/somewhere/resultnode" as="iter"
>   assign
>     from query="$in/somewhere/resultnode[$iter}"
>     to query="$out/elsewehere/node[$iter]"
> 
> This will avoid to introduce the new alias concept, since assignes only
> know about their normal semantics (with the exception of a read only
> integer).
> 
> If we go with the alias iterator, I am not sure about how to collect
> results. I guess that was Ivanas question, too. We could assign the
> results back to the request message, however I think this is untypical
> for process design and counter intuitive for modellers who like to have
> a in-type and an out-type.
> 

There are actually a couple of downsides to the number approach. First, 
it can be very misleading. If someone is editing the iterated variable 
in parallel then it is possible for items to move around. Imagine that a 
foreach expression generates 4 results. This will cause the for-each to 
count from 1 to 4. On the second iteration the code looks ahead to the 
third iteration to see what value is coming up and makes a decision on 
that basis. But after the second iteration ends but before the third 
iteration begins the variable being iterated over is modified so that 
the third entry is missing. Now the third iteration begins but it is 
actually processing the 4th value, not the 3rd value. But what's much 
worse is that the decisions made on the 2nd iteration were based on the 
value of the 3rd entry. But now the 3rd entry is gone but the foreach 
doesn't know that! So it will process what is really the 4th entry, 
thinking it is the 3rd entry and all hell will break lose. In addition 
when the 4th iteration arrives the integer will point to an empty node 
set (in XPATH 1.0 terminology) which will almost certainly break the 
programmer's code unless they put in explicit checks.

Second, using iterators in this way is more complex for the programmer 
because now they have to throw in XPATHs with iterator values all over 
the place.

For what its worth I don't think the numeric iterator pattern is 
necessarily a bad one. I just think it is less optimal than the alias 
pattern.


> D) iteratorVariableType <- I guess it is allowed to do static checking
> if the type is possible? I would change the wording for the verify, so
> that the engine will asume the iterator is of the specified type, and
> may check if it is assignment compatible. With the int-iterator it is
> however a non-issue.
> 

That is what the validate attribute is for.

> Greetings
> Bernd
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>