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