RE: Issue 147 - some comemnts and questions

["Eckenfels. Bernd" <B.Eckenfels@seeburger.de>]

Hello Everybody,

Thanks to Yaron, for his pointer to the open issue in discussion.

I also think the for-each construct is very important and I like the
general idea Yaron is going with his proposal. However I have some
additional comments (partially agreeing with Danny).


Minor Note:

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?

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.

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.

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.

Greetings
Bernd