[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Action Items for undefined behavior
> ford: Diane suggested I post this to the mailing list but after the > spec editing team call it was decided to open an issue to track all of > the undefined behavior in a single issue so as to give people enough > time to review and comment. mm1: We just closed Issue #144 because the TC decided not to track all undefined behaviors in a combined issue, but handle them on a case by case basis as individual issues. Are we revisiting that decision? [1] Reference: http://lists.oasis-open.org/archives/wsbpel/200602/msg00108.html > ------------------------------------------------------------------------ > *From:* Danny van der Rijn [mailto:dannyv@tibco.com] > *Sent:* Wednesday, March 08, 2006 1:50 PM > *To:* Mark Ford > *Cc:* wsbpeltc > *Subject:* Re: [wsbpel] Action Items for undefined behavior > > Mark Ford wrote: > >> I should have brought this up during the call but I was concentrating >> on taking minutes ;) >> >> If there are no objections, I will open action items for the >> following spec text below that still contains undefined behavior. >> >> *#1 undefined changes to bpws:missingReply* >> 5.5 The Lifecycle of a Business Process >> (Paragraph 8) >> A receive activity for an inbound request/response operation is said >> to be open if that activity has been performed and no corresponding >> reply activity has been performed. If the process instance reaches >> the end of its behavior, and one or more receive activities remain >> open,* then the status of the instance becomes undefined*. This >> condition indicates a modeling error that was not detected by static >> analysis. >> > > Given that this is now much better spelled out, I would prefer just > removing this paragraph altogether: It is now not possible for a > process to reach the end of its behavior with an open IMA that hasn't > caused a fault already. We may need to move the first sentence > defining an open receive, although we'd have to reword it as an open > IMA now anyway. > >> *Action:* Change to the following: >> A receive activity for an inbound request/response operation is said >> to be open if that activity has been performed and no corresponding >> reply activity has been performed. If the process instance reaches >> the end of its behavior, and one or more receive activities remain >> open,* then the process faults with a bpws:missingReply*. This >> condition indicates a modeling error that was not detected by static >> analysis. >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]