[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
I'm not a regular contributor (just an observer) but I just want mention our experience on this issue. We are using BPEL in a B2B framework for "private process" orchestrations (ie to deliver compliance to the community standard "public process"). XML manipulation is clearly a significant part of the "private process" and we make heavy use of xslt, xforms, xquery, etc. I can't see why bpel would want to duplicate these specifications. A better approach would be to agree a standard WS interface to invoke applications like Apache xalan or Microsoft WSE that implement these specs. More generally, it would be nice if every standard that could possibly be implemented by an application and exposed as a service had an associated web services profile in it's normative specification document. For example: A standard WSDL portType definition A standard UDDI meta-data structure and canonical tModel urn/UUID A standard set of WS-Policy Assertions (except that WS-Policy is not yet an "open" standard :( Then I could write a re-usable bpel to invoke an xslt processor without worrying about the syntax and semantics of specific product interfaces. For example, the BPEL specification itself (Nov 2003 draft) seems not to provide a urn to identify the specification (apologies if I am wrong here - but a search on "urn:" returns nothing). I need to create a UDDI tModel to represent bpel as a specification so that compliant implementations can be classified - what urn/UUID do I use? If I invent one then how can I be sure that my meta-data will be interoperable with other uddi nodes? The WS-xx specs that I have had a chance to read are a bit inconsistent in this area - some provide this kind of data and others dont. Regards, Steve Capell RedWahoo Sydney, Australia Tel : +61 410 437854 This email message and any accompanying attachments may contain information that is confidential and is subject to legal privilege. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately, and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of Red Wahoo Pty. Ltd. Before opening any attachments, please check them for viruses and defects. We do not accept any liability for loss or damage which may arise from your receipt of this e-mail. -----Original Message----- From: Satish Thatte [mailto:satisht@microsoft.com] Sent: Wednesday, 4 February 2004 11:53 AM 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/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_workgroup. php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]