wsbpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsbpel] Action Items for undefined behavior
- From: "Mark Ford" <mark.ford@active-endpoints.com>
- To: "'Diane Jordan'" <drj@us.ibm.com>,"'Monica J Martin'" <Monica.Martin@Sun.COM>
- Date: Wed, 8 Mar 2006 15:52:07 -0500
FYI - Diane is referring to three issues because my original email sent
to her and Peter identified three undefined behaviors. The email I sent to the
list after today's TC call only contained two of the items which I thought were
simple editorial changes (language about bpws:missingRequest
and bpws:missingReply).
The item I left off the list stated that a missing propertyAlias should
result in a bpws:selectionFailure. This language was introduced with Issue 145
but is not in the current draft. I left this off based on
today's discussion of static analysis. It seems to me that missing
properties or propertyAliases should be caught during static analysis. I can see
where this particular issue might spark some debate hence my leaving it off my
"Action Items" suggestion.
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]