[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 147 - Serial and Parallel For-Each
The code at the bottom was just meant to give an idea of how for-each could be made to work in BPEL as it exists today. It is not normative. It would not go into the spec. The spec would define for-each as a basic operation similarly to how it defines while or switch. Yaron Alex Yiu wrote: > > > One short question: > Is "currentInstanceNum" a fixed / default variable name for the integer > counter for the forEach? > > > Regards, > Alex Yiu > > > ws-bpel issues list editor wrote: > >> This issue has been added to the wsbpel issue list. The issues list is >> posted as a Technical Committee document to the OASIS WSBPEL TC pages >> <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a regular >> basis. The current edition, as a TC document, is the most recent >> version of the document entitled in the "Issues" folder of the WSBPEL >> TC document list >> <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - >> the next posting as a TC document will include this issue. The list >> editor's working copy, which will normally include an issue when it is >> announced, is available at this constant URL >> <http://www.choreology.com/external/WS_BPEL_issues_list.html>. >> >> >> Issue - 147 - Serial and Parallel For-Each >> >> *Status:* open >> *Categories:* Syntax and validation <#category_syntax_and_validation> >> *Date added:* 16 Jul 2004 >> *Submitter:* Yaron Y. Goland <mailto:ygoland@bea.com> >> *Date submitted:* 15 June 2004 >> *Description:* For-each is a very common control structure that has >> special appropriateness to BPEL where one can routinely expect BPELs >> to need to iterate through XML structures. One can easily imagine two >> flavors of for-each. Serial and parallel. Note: These same ideas have >> been proposed in issue 63 <#Issue63> and issue 4 <#Issue4> but both of >> those issues could be resolved in ways that do not necessarily use the >> for-each construct. Therefore I am proposing for-each on its own. If >> 63 and 4 are closed by introducing serial and parallel for-each then >> this issue can also be closed. >> *Submitter's proposal:* >> >><foreach iteratorVariableName="ncname" iteratorVariableType="qname"\ >> parallel="xs:Boolean" standard-attributes> >> standard-elements >> <expression expressionLanguage="anyURI">...</query> >> activity >></foreach> >> >> >> The expression element would be responsible for returning a node-set >> with 0 or more nodes in it. Each node MUST be of the type specified by >> iteratorVariableType. >> >> If parallel equals false then each node would be assigned, serially >> and in document order, to the variable created in an implicit local >> scope by the attribute iteratorVariableName and the activity would be >> executed. After the activity successfully completes the variable would >> be assigned to the next node and the activity run again. >> >> If parallel equals true then a series of parallel scopes, with the >> same operational semantics as parallel executing event handlers, equal >> in number to the number of nodes in the node-set would be created and >> each node would be assigned to a variable local to each of the scopes. >> >> Note that the scope in which the iterator variable is defined is local >> to the foreach activity and does not contain either an implicit fault >> or compensation handler. The lack of these handlers is very similar to >> the logic that was discuss at the 6/2004 F2F for issue 126 <#Issue126>. >> >> For example: >> >>foreach iteratorVariableName="anOrder" iteratorVariableType="b:ar"/ >> expression >> expressionLanguage="http://www.w3.org/TR/1999/REC-xpath-19991116"; <http://www.w3.org/TR/1999/REC-xpath-19991116> >> parallel="false" >> $orderManifest/somePart/ordermanifest/orders >> ... >> >> >> Would be equivalent to: >> >>scope >> variables >> variable name="anOrder" type="b:ar" >> variable name="currentInstanceNum" type="xs:int" >> sequence >> assign >> replace >> from expressionLanguage="static" >> "1" >> to expressionLanguage="xpath" >> $currentInstanceNum >> while >> condition expressionLanguage="xpath" >> $currentInstanceNum <= count($orderList/somePart/ordermanifest/orders) >> sequence >> assign >> replace >> from expressionLanguage="xpath" >> $orderList/somePart/(ordermanifest/orders)[$currentInstanceNum] >> to expressionLanguage="xpath" >> $anOrder >> assign >> replace >> from expressionLanguage="xpath" >> $currentInstanceNum+1 >> to expressionLanguage="xpath" >> $currentInstanceNum >> ... >> >> >> >> *Links:* Yaron Y. Goland, 25 Mar 2004 >> <http://lists.oasis-open.org/archives/wsbpel/200403/msg00215.html> >> Yaron Y. Goland, 25 Mar 2004 >> <http://lists.oasis-open.org/archives/wsbpel/200403/msg00216.html> >> *Changes:* 16 Jul 2004 - new issue >> >> To comment on this issue, please follow-up to this announcement on the >> wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org> list >> (replying to this message should automatically send your message to >> that list), or ensure the subject line as you send it *starts* "Issue >> - 147 - [anything]" or is a reply to such a message. If you want to >> formally propose a resolution, please start the subject line "Issue - >> 147 - Proposed resolution", without any Re: or similar. >> >> To add a new issue, see the issues procedures document (but the >> address for new issue submission is the sender of this announcement). >> >> To unsubscribe from this mailing list (and be removed from the roster >> of the OASIS TC), go to >> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]