[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
Edwin, The "etc" should also include OASIS CAM as a means to assemble and manage transaction content. Thanks, DW ----- Original Message ----- From: "Edwin Khodabakchian" <edwink@collaxa.com> To: "'Pal Takacsi-Nagy'" <pal@bea.com>; "'Danny van der Rijn'" <dannyv@tibco.com> Cc: <wsbpel@lists.oasis-open.org> Sent: Tuesday, February 03, 2004 3:11 PM 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/leave_workgroup. > 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_workgroup. > 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_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]