[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 11 - Creation of Repeating/Optional XML Structures
David, I think you've taken the particular for the general. What you propose *is* an array within the sense Alastair meant (or at least, in the sense of the conversation I had with him just before he sent the message). It's a collection of similar chunks of information, with the possibiility of use or source of each chunk separately in the business process, and the possibility of dealing with the whole. How, in current BPEL, would you add bidline elements to the Bids ? Processing the totality, once you've got it together, would probably be done as you suggest. But making the "iterator" and "concatenator" operations into external services would rather detract from the utility of the process language. Note that the requirement (and the implication of issue 4 (issue list "working copy" - http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue4) includes having collections of endpoints, as well as data. Hmm - and the ability to relate one to the other, come to think of it. Peter > -----Original Message----- > From: David RR Webber [mailto:david@drrw.info] > Sent: 04 February 2004 14:46 > To: Green, Alastair J.; Satish Thatte; edwink@collaxa.com; > Pal Takacsi-Nagy; Danny van der Rijn > Cc: wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue 11 - Creation of > Repeating/Optional XML Structures > > > Alistair, > > OK - I need to climb on my soap box. ARRAYS are death to > interoperability. > > Do not think arrays! > > Notice that you can use an XML structure to carry the type of > information you require. > > <Bids> > <Bidline ownerID="1"> stuff </Bidline> > <Bidline ownerID="2"> more stuff </Bidline> > <Bidline ownerID="3"> other stuff </Bidline> > </Bids> > > I believe this is closer to what you want anyway - where > bidders can have bidlines added as each happens and they send > it to you, and then you simply process the complete XML > instance with an external call to some webservice and pass it > the XML structure > > e.g. --> reviewCurrentBids ( Bids ) and return a condition to BPEL > > of the winning bid, or a continuation of the auction. > > DW. > > ----- Original Message ----- > From: "Green, Alastair J." <Alastair.Green@choreology.com> > To: "Satish Thatte" <satisht@microsoft.com>; > <edwink@collaxa.com>; "Pal Takacsi-Nagy" <pal@bea.com>; > "Danny van der Rijn" <dannyv@tibco.com> > Cc: <wsbpel@lists.oasis-open.org> > Sent: Wednesday, February 04, 2004 5:47 AM > Subject: RE: [wsbpel] Issue 11 - Creation of > Repeating/Optional XML Structures > > > If the current spec does not support the ability to read some > configuration of n counterpart services, traverse that array > and invoke on those services, and then cause delivery of that > array to some other service or function, then I think Danny > is right to say that BPEL is crippled. Is this not the > subject of Issue 4 (an original submitters' issue), as well > as this issue? > > We have a standard demo, where a hedge fund connects to > (configurable) n market makers, and requests quotes for > securities or options (ideally in parallel). We then examine > the results and make a decision as to which > (single) security and which (single) option we want to > select. This selection would involve transmission of an order > message to the selected market makers for each of the > security and the option. > > How would this simple process be modelled in the current form of BPEL? > > Alastair > > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: 04 February 2004 00:53 > To: edwink@collaxa.com; Pal Takacsi-Nagy; Danny van der Rijn > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue 11 - Creation of > Repeating/Optional XML Structures > > I really like Edwin's suggestion of letting the XML data > manipulation standards work be done properly where it > belongs. We would be foolish to take on some arbitrary > subset and address that in an ad hoc and separate effort from > the mainline XML efforts. > > We already made sure that we can open up to those future > standards by resolving Issue 13 the way we did. Let us not > open this can of worms. > > Satish > > -----Original Message----- > From: Edwin Khodabakchian [mailto:edwink@collaxa.com] > Sent: Tuesday, February 03, 2004 12:11 PM > To: 'Pal Takacsi-Nagy'; 'Danny van der Rijn' > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue 11 - Creation of > Repeating/Optional XML Structures > > Data manipulation is indeed a must have which people usually > address by calling out (through web service invocation or > XPATH function call) to a transformation service implemented > in XQuery, XSLT, XML Beans, etc. > > Usability could be greatly improved through the mechanism > Alex is suggesting but it would also introduce a lot of > details/issues to be ironed out. So the question is not > should we do it or not but should we do it now or wait for > the next revision of the spec. > > Edwin > > > -----Original Message----- > From: Pal Takacsi-Nagy [mailto:pal@bea.com] > Sent: Tuesday, February 03, 2004 11:38 AM > To: edwink@collaxa.com; 'Danny van der Rijn' > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue 11 - Creation of > Repeating/Optional XML Structures > > Doesn't not having proper support for data manipulation will > result in incompatible implementation in BPEL? In can't think > of any real life workflow that does not have data > transformation in it. If all vendors have to do it their own > way this will compromise the value of the standard IMHO. > > -----Original Message----- > From: Edwin Khodabakchian [mailto:edwink@collaxa.com] > Sent: Tuesday, February 03, 2004 11:13 AM > To: 'Danny van der Rijn' > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue 11 - Creation of > Repeating/Optional XML Structures > > Danny, > > There is now doubt that today BPEL is crippled because it > only supports very limited data manipulation (data > initialization, array/looping, update). There is also no > doubt that this is a slippery slope. > > One option might be to allow tighter integration between BPEL > and XQuery (as suggested by Alex Yiu earlier in this forum). > > But even that integration work might be out of the scope of > the initial delivery of the spec as this is something that > can be layered on at a later point of time without impacting > to our current work. > > Edwin > > -----Original Message----- > From: Danny van der Rijn [mailto:dannyv@tibco.com] > Sent: Tuesday, February 03, 2004 10:33 AM > To: wsbpel@lists.oasis-open.org > Subject: [wsbpel] Issue 11 - Creation of Repeating/Optional > XML Structures > > At our September F2F, I presented some alternatives for > addressing issue 11. The alternative were met with some > opposition to even addressing the issue at all. In order to > get the conversations going again, I'd like to present a very > high level view of the pros and cons of addressing the issue. > It seems most appropriate to me to begin at this level, > before spending any more time actually trying to solve the issue. > > The issue: To modify a variable's XML structure, one uses > the <assign> <from/> <to variable="ncname" part="ncname"? > query="queryString"?/> </assign> syntax. > > "For XPath 1.0, the value of the query attribute MUST be an > absolute locationPath (with '/' meaning the root of the > document fragment representing the entire part). It is used > to identify the root of a subtree within the document > fragment representing the part. The location path MUST select > exactly one node. If the location path selects zero nodes or > more than one node during execution, then the standard fault > bpws:selectionFailure MUST be thrown by a compliant implementation." > > What this ends up meaning is that if there is a repeating > element that has N instances of the element, the N+1th may > not be created. Additionally, if there is an optional > element that is not present, it can not be created. > > Pro-Issue 11: There are many use cases where the creation of > repeating and/or optional elements is required. A notable > one is looping over an array of inputs, calling a service on > each one, and creating an array of outputs. There are many > more. BPEL would be crippled without this feature. > > Anti-Issue 11: BPEL has some very primitive data handling > capabilities, but should never have full-blown data handling > capabilities. If the language is modified to solve this > problem, we are starting down a slippery slope. What will the > next data handling addition be? When will the ocean be > boiled? If data handling capabilites beyond what are > currently included are needed, then simply call out to a data > handling/modification service. > > > 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/le ave_workgr oup. php. 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_workgr oup. php. 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_workgr oup.php. 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_workgr oup.php. 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_workgr oup.php. 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_workgr oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]