Re: [wsbpel] New and updated WS-BPEL issues

[Diane Jordan <drj@us.ibm.com>]

Thanks Tony - we really appreciate your
efforts to help with this.  
Here is my understanding of the questions
you brought up:  
12.1 was proposed and closed at the
f2f - it is essentially described in this email:  
http://lists.oasis-open.org/archives/wsbpel/200412/msg00054.html
which was initially sent as a proposal to close issue 12.  During
the discussion, it was decided that hte proposal didn't cover every case
of issue 12 and so it was accepted as a partial solution (thus creating
12.1 and closing it right away) and issue 12.2 was created to describe
the rest of the issue.  

Issue 183 will be covered in the Jan
19 meeting - it was first brought up at the f2f and discussed at that time.
 We deferred it from the Jan 5 meeting since all the interested parties
weren't present.  Unless there is another good reason to defer, we
should decide whether to open it at this meeting.  

Regards, Diane
IBM  Emerging Internet Software Standards
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709

"Tony Fletcher" <tony_fletcher@btopenworld.com>

01/18/2005 01:35 PM

To	<wsbpel@lists.oasis-open.org>
cc
Subject	[wsbpel] New and updated WS-BPEL issues

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: tony.fletcher@choreology.com
Home: amfletcher@iee.org