[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 260 - Confusing pargraph describing on suppressJoinFailuremechanism
Sure we can try to reword it ... :-) Regards, Alex Yiu Dieter Koenig1 wrote: >Hi Alex, after having clarified this, do we agree that the "invoke with >FH/CH"-scope and the "suppressJoinFailure"-scope are two independent >"macros"? > >This is what the paragraph is trying to illustrate, and I would like to >keep it (maybe we find even more clear words where necessary :-). > >Kind Regards >DK > > Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH > > Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220 > > Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen > > Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany > > > > > > > > Alex Yiu > <alex.yiu@oracle. > com> To > Mark Ford > 10.04.2006 19:15 <mark.ford@active-endpoints.com> > cc > Alex Yiu <alex.yiu@oracle.com>, > wsbpeltc > <wsbpel@lists.oasis-open.org> > Subject > Re: [wsbpel] Issue - 260 - > Confusing pargraph describing on > suppressJoinFailure mechanism > > > > > > > > > > > >Hi Mark, >(cc'ing the rest of TC) > >Thank you pointing that out. Yes, <invoke> does have both inline CH and >inline FH. >I was rushing too quickly in terms of syntax verification before filing the >issue. > >Readers of this issue description: Please ignore this particular statement >in the issue description: >"First of all, <invoke> can only have an inline CH, not an inline FH." > >Doing a marathon review does sometimes make one's brain fried. :-) >One should not file an issue right after an lengthy review session. :-) > >Mark ... thanks again! > > >Regards, >Alex Yiu > > >Mark Ford wrote: > Hi Alex, > > You wrote: > > "First of all, <invoke> can only have an inline CH, not an inline FH. > And, the example does not have an inline CH per see." > > An <invoke> can have both CH and FH declared inline. There's no > <faultHandlers> element but <catch> and <catchAll> are allowed. > > > From: ws-bpel issues list editor [mailto:peter.furniss@erebor.co.uk] > Sent: Friday, April 07, 2006 4:38 PM > To: wsbpel@lists.oasis-open.org > Subject: [wsbpel] Issue - 260 - Confusing pargraph describing on > suppressJoinFailure mechanism > > > > This issue has been added to the wsbpel issue list with a status of > "received". The status will be changed to "open" if a motion to open > the issue is proposed and that motion is approved by the TC. A motion > could also be proposed to close it without further consideration. > Otherwise it will remain as "received". > > > The issues list is posted as a Technical Committee document to the > OASIS WSBPEL TC pages on a regular basis. The current edition, as a > TC document, is the most recent version of the document entitled in > the "Issues" folder of the WSBPEL TC document list - the next posting > as a TC document will include this issue. The list editor's working > copy, which will normally include an issue when it is announced, is > available at this constant URL. > > > Issue - 260 - Confusing pargraph describing on suppressJoinFailure > mechanism > Status: received > Date added: 7 Apr 2006 > Categories: Joining > Date submitted: 07 April 2006 > Submitter: Alex Yiu > Description: During the review of Chapter 11, Danny and I have share > some similar concerns about the paragraph below. > > > Note that the name of the scope created to suppress the > bpel:joinFailure fault that immediately encloses an activity > with a join condition is exactly the same as the name of the > activity itself. In case this is an invoke activity (see 10.3. > Invoking Web Service OperationsInvoking Web Service Operations) > with an inlined fault or compensationHandler, join failure > suppression is applied to the implied scope of the <invoke> > activity; i.e. effectively two scopes are implied: an outer > scope containing an empty faultHandler for the bpel:joinFailure > fault and an inner scope containing the links, faultHandlers, > and compensationHandlers of the original <invoke> activity. > Identical rules apply to <scope> activities: a <scope> with > join failure suppression enabled implies an additional > surrounding scope.. > > > The paragraph seems to imply that the scope created to suppress > joinFailure is not that virtual, but quite user visible. It goes out > of its way to explain there is a name for that created scope. And, > there are two level of scopes. > > > Also, the description also said the inner scope is for the inlined > fault handler and compensation handler. First of all, <invoke> can > only have an inline CH, not an inline FH. And, the example does not > have an inline CH per see. > > > They are quite confusing and misleading to some readers. > Submitter's proposal: All in all, I would suggest to remove that > paragraph . If we want to retain that paragraph, we need some major > rewording there. > > > Also, in a paragraph occurring in the Chapter earlier: "Suppressing > the bpel:joinFailure fault is equivalent/similar to surrounding each > affected activity with a <scope> activity that defines an "empty" > faultHandler for the bpel:joinFailure fault.", we should also stress > the scope is a virtual scope and exists only for purpose of > suppressing joinFailure and has no other usage / impact (e.g. no > effect on compensation). > Changes: 7 Apr 2006 - new issue > > > > > > To comment on this issue (including whether it should be accepted), > please follow-up to this announcement on the > wsbpel@lists.oasis-open.org list (replying to this message should > automatically send your message to that list), or ensure the subject > line as you send it starts "Issue - 260 - [anything]" or is a reply > to such a message. If you want to formally propose a resolution to an > open issue, please start the subject line "Issue - 260 - Proposed > resolution", without any Re: or similar. > > > To add a new issue, see the issues procedures document (but the > address for new issue submission is the sender of this announcement). > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]