Re: [wsbpel] Action Items for undefined behavior

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

My recollection was that 144 was deferred
until after the restructure and at that time when we revisited it, no one
had any instances of undefined behavior to correct.  So we closed
it with the provision that we'd open new issues when instances were uncovered.
 If we'd had a list of instances then, I would have suggested that
we close 144 with the specific changes related to those (and we might still
have said that if any more were found in the future we'd open issues to
 correct them also). 
 
Its not clear to me that each instance
necessarily needs a separate issue though, and it may even be appropriate
for some to go directly to the action item list if they are simple enough.
 The spec editing team discussed this possibility - however, for this
set, there was a question about the first instance and therefore it seemed
better to get it posted to the full TC with an issue number so we could
track any discussion.  So, I think we're in line with the thinking
when we closed 144 - these are three specific instances that have been
identified.  I didn't suggest opening three issues as it didn't seem
like it would be overly complicated to keep track of them in one issue
- however, if the TC thinks 3 separate issues would be better, we could
go that route. 

It might also be good if these become
a point issue (or issues) on 144 to make the connection explicit.  That
also stream lines the opening process.   

Whichever way we go,  thanks to
Mark for his review that caught these cases.   
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

Monica J Martin <Monica.Martin@Sun.COM>

03/08/2006 02:12 PM

To	Mark Ford <mark.ford@active-endpoints.com>
cc	"'Danny van der Rijn'" <dannyv@tibco.com>, "'wsbpeltc'" <wsbpel@lists.oasis-open.org>
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.
>>
>>



---------------------------------------------------------------------
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