OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue 147 - Proposal For Vote



Hi all,

I am also interested in investing some of my "brain cycles" to create an 
extended proposal to cover the iterator aspect to make this activity a 
real "forEach" activity.
(That I have already expressed that to Yaron in another one-on-one email 
thread.)

On the other hand, I also agree with Yaron that time is running out for 
this spec cycle. We need to box the time spent in this issue proposal. 
If we cannot find a way to describe the behavior of iterator variable 
simple, portable and still flexible enough within a week or two, we may 
want to throw in the "white towel" ... to declare that we decide not to 
cover iterator aspect of this activity in this cycle  (by opening a 
sub-issue and close it with revisiting in next cycle of spec)

Thanks!


Regards,
Alex Yiu



Eckenfels. Bernd wrote:

>Hello Yaron,
>
>I am pretty suprised that you changed your proposal that quickly. :) If
>somebody still thinks about your fist object-oriented-alias iterator, I
>would be happy to brain storm it on that a bit more. Besides the
>complexity of input-output/snapshot/concurrent/slot-reservations id had
>some charme.
>
>Otherwise if everybody agrees that the simple counter solution is the
>way to go I think your proposal for that way is great, covering all the
>aspects needed.
>
>(To make it a bit more simple I would remove the count-direction and
>enforce counting from start to end in +/-1 steps automatically -or- keep
>the definded direction as step=int?)
>
>Greetings
>Bernd
>
>-----Original Message-----
>From: Yaron Y. Goland [mailto:ygoland@bea.com] 
>Sent: Monday, April 18, 2005 8:00 PM
>To: wsbpeltc
>Subject: [wsbpel] Issue 147 - Proposal For Vote
>
>147 - Serial and Parallel Foreach
>
>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
>
>12.6 - foreach
>
><forEach counterName="ncname" parallel="yes|no" count="up|down"? 
>standard-attributes>
>     standard-elements
>     <startCounterValue expressionLanguage="anyURI">
>        ...
>     </startCounterValue>
>     <finalCounterValue expressionLanguage="anyURI">
>        ...
>     </finalCounterValue>
>     Scope
></foreach>
>
>The foreach activity is an iterator that will repeat its contained scope
>activity exactly N+1 times where N equals the absolute value of the
>value returned by the expression in <startCounterValue> subtracted from
>the value returned by the expression in <finalCounterValue>.
>
>When the foreach activity is started the expressions in
><startCounterValue> and <finalCounterValue> are evaluated. Both
>expressions MUST each return a value of type xs:int or the
>bpws:forEachCounterError fault MUST be thrown. If the expression
>language used in either element happens to be
>urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0 then the expressions
>contained in the two elements MUST be wrapped in implicit calls to the
>round(number()) functions.
>
>The count attribute is optional and defaults to "up". If count equals
>"up" and the startCounterValue is greater than the finalCounterValue or
>if count equals "down" and the startCounterValue is less than the
>finalCounterValue then a bpws:forEachCounterError fault MUST be thrown. 
>It is always legal to have the startCounterValue equal the
>endCounterValue regardless of the value of the count attribute.
>
>The Scope activity MUST NOT have a variable explicitly declared in it
>with the same name as contained in the counterName attribute, a
>violation of this requirement MUST be detected statically.
>
>If parallel="no" then this is a serial foreach where the enclosed scope
>activity will be repeated N+1 times. During each repetition a variable
>of type xs:int will be created on the enclosed scope activity with the
>name specified in the counterName attribute. The counter variable's
>creation and initialization MUST occur before any other variables on the
>enclosed scope activity are declared, therefore other variables declared
>on the enclosed scope activity MAY refer to the counter variable in
>their own initializations. The counter variable is local to the enclosed
>scope and although its value can be changed during an iteration that
>value will be lost when the enclosed scope exits and will not affect the
>value that the next iteration's counter will be set to.
>
>The first iteration of the scope will see the counter variable set to
>the startCounterValue. The next iteration will cause the counter
>variable to be set to the startCounterValue plus one if the count
>attribute equals "up" or by minus one if the count attribute equals
>"down". Each subsequent iteration will increment/decrement the
>previously initialized counter value until the final iteration where the
>counter will be set to the finalCounterValue.
>
>If parallel="yes" then this is a parallel foreach where the N+1
>instances of the enclosed scope activity will occur in parallel. In
>essence an implicit flow is dynamically created with N+1 copies of the
>foreach's enclosed scope activity as children. Each copy of the scope
>activity will have the same counter variable defined in the same manner
>as specified for serial foreach with the exception that each counter
>variable will be uniquely initialized to one of the integer values
>starting with startCounterValue and covering all integer values up to
>and including finalCounterValue. In the case of parallel foreach the
>count attribute acts as a validator of the startCounterValue and
>finalCounterValue.
>
>Add to Appendix A:
>
>forEachCounterError - Either the startCounterValue or finalCounterValue
>returned non-integer values or their relative values violated the
>constraint specified by the count attribute.
>
>
>---------------------------------------------------------------------
>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 
>
>
>---------------------------------------------------------------------
>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]