[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Issue 147 - some comemnts and questions
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]