← Prev in month
← Prev in thread
New and updated WS-BPEL issues
Title: Message Dear Colleagues, I would like to draw some new issues to your attention. At Yaron's request I have added (as 'received' ) sub-issue 12.2 - and I am still trying to find out what happened to 12.1 - answers on the back of a (pretty) postcard please! Then there are three new issues for the TC's consideration 182 (where I have modified the description at Alex's request - I assumed this was all right as we still have a week to go before we consider it at the next TC meeting), 183 and 184. The latest issues list is available at http://www.choreology.com/external/WS_BPEL_issues_list.html for your review and I plan to put a copy on the OASIS site just before the meeting next week. At Diane's request and suggestion I have added some cross linking on a few issues to show strong interrelationship. See for instance Issue 103 and Issue 28, Issue 29, Issue 102, Issue 153 and Issue 156. Please obey the rules as previously stated when sending mail about issues. (I am currently unable to run the script that usually generates the new issue messages.) Please send further new issues,any comments / anomaly notifications (etc.) to myself (Tony Fletcher) with a copy to Peter Furniss for the present. Thank you. Issue 12.2: Accessing messageType properties under issue 12 Status: received Date added: 7 Jan 2005 Categories: Data handling Date submitted: 23 December 2004 Submitter: Yaron Y. Goland Description: If someone has defined a property on a messageType and a programmer uses issue 12.1 : to pass in and out an element for that messageType then how does the programmer get access to the messageType specific properties? After all, if they pass the element into getVariableProperty they will (per issue 145 : Properties on Non-Message Variables ) only get the properties defined on the element, not the messageType. This issue is being opened as a result of the resolution of issue 12.1. Submitter's proposal: I don't have one yet. Links: Changes: 7 Jan 2005 - new sub-issue Issue 182: How to add bodies later to BPEL faults without breaking BPEL code written assuming there is no fault body? Status: received Date added: 6 Jan 2005 Categories: Fault handling Date submitted: 15 December 2004 Submitter: Alex Yiu Champion: Alex Yiu Document: BPEL specification Description: According to our current fault matching rules IF a fault has a body THEN it can only be three ways - by a catch that specifies the name and body, by a catch that just specifies the body or by catch all. But notice what can't catch it, a catch that just catches on the name. That means, if someone needs to add a data body to the fault later (to add optional interesting data) then all existing catches will be broken. How do we make it possible for people to later add bodies to BPEL faults without breaking BPEL code written assuming there is no fault body? Please note that this problem already affect us on BPEL standard faults. We define BPEL standard faults with their name but without their bodies. If an implementation decides to introduce extra fault information in the body later, all existing fault handlers for that fault will not work. We need to ask users to change their fault handlers or add new fault handlers. Proposed Solution: (A) allow <catch faultName="qname"> to catch with fault data body as well ? (B) introduce a standard fault body that is thrown with all BPEL standard faults. And, the fault body will contain an xsd:any ? (C) add new version of fault handler that specifies both a name and a body and can catch either just on name or on both name and body ? (D) Other ideas .... ? Links: Original message, 15 Dec 2004 Alex Yiu, 12 Jan 2005 Yaron Y. Goland, 14 Jan 2005 Changes: 6 Jan 2005 - new issue; 13 Jan 2005 - fields: Links; 14 Jan 2005 - fields: Links Issue 183: Ambiguity in Rethrow Semantics Status: received Date added: 7 Jan 2005 Categories: Fault handling Date submitted: 23 December 2004 Submitter: Yaron Y. Goland Description: If one catches a fault and then modifies the fault variable and then rethrows the fault what is rethrown? The original fault variable or the modified fault variable? Similarly, with issue 12 : XML types and WS Interactions , if someone catches a messageType fault using an element based catch and then uses rethrow, what is rethrown, the original messageType fault or the element that was caught? Submitter's proposal: Clarify the language to specify that the original fault is always rethrown regardless of what variable is bound or modified. So in the first example above the original variable, not the modified version, would be rethrown. In the second example the original messageType variable and not the element variable would be rethrown. Links: Changes: 7 Jan 2005 - new issue Issue 184: Fully Specify Examples Status: received Date added: 18 Jan 2005 Categories: Specification Editing Date submitted: 13 January 2005 Submitter: Yaron Y. Goland Description: Section 6.1 includes an example which imports schema elements from the (fictitious) namespace "http://manufacturing.org/xsd/purchase". But the actual contents being imported are never specified so the example cannot be implemented. Submitter's proposal: We should provide actual schema definitions (they can be trivial), even if just in an appendix, so that all of our examples are fully implementable. Changes: 18 Jan 2005 - new issue Best Regards, Tony Tony Fletcher Technical Advisor Choreology Ltd. 68, Lombard Street, London EC3V 9L J UK Phone: +44 (0) 1473 729537 Mobile: +44 (0) 7801 948219 Fax: +44 (0) 870 7390077 Web: www.choreology.com Cohesions™ Business transaction management software for application coordination Work: Home:
← Prev in month
← Prev in thread