Next in thread →
Next in month →
RE: [wsbpel-spec-edit] undefined behavior
Title: Message
I've
put Mark's original three items in a issue 246, which was my interpretation of
the desired action from the editor's meeting yesterday. Hope I got that right,
or near right
Peter
-----Original Message-----
From: Diane Jordan
[mailto:]
Sent: 08 March 2006 14:43
To:
Peter Furniss
Cc: 'Mark Ford';
Subject: [wsbpel-spec-edit]
undefined behavior
My
recollection is that when we closed 144 we said that no undefined behaviors
had been identified after the restructure and that any that were found should
have issues opened. However, if these are trivial, an action item should
be ok. As the first of their class it might be best to review them
with the TC.
Mark, if you
think action items are ok, please resend this to the TC list with the note
that we will open action items for the spec editing team unless there is an
objection. (I've copied the spec editing team - they may want to weigh
in beforehand).
Regards,
Diane
IBM Emerging Internet Software
Standards
(919)254-7221 or 8-444-7221, Mobile:
919-624-5123, Fax 845-491-5709
"Peter Furniss"
<>
03/08/2006 02:24 AM
To
"'Mark Ford'"
<>, Diane
Jordan/Raleigh/IBM@IBMUS
cc
Subject
RE: new
issue
Whoops - I found this in my inbox. But I seem to
remember some message (from Diane ?) leading me to think there was some doubt
about whether it should go in.
I'm happy to put it in, and apologise if I've
just been asleep on this. Mark - do you want it submitted as an issue (and if
so, can you give me a title please). Or is it just a candidate for the action
items ?
(Hope to be on the call tomorrow, but don't expect to be
able to update the issue list until later in the evening, or sometime on
Thursday).
Peter
-----Original
Message-----
From: Mark Ford [mailto:]
Sent: 28 February 2006 15:47
To: 'Peter Furniss'; 'Diane
Jordan'
Subject: new issue
In response to closing Issue 144, there are still a
few places in the current working draft that mention undefined behavior. I'm
not sure if these are "issue worthy" or not since they are pretty straight
forward.
#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.
Change to:
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.
#2 undefined changes to
bpws:selectionFailure
Section 8.3 Expressions
(2nd to last paragraph)
This function extracts global property values from
variables. The first argument names the source variable for the data and the
second is the qualified name (QName) of the global property to select from
that variable (see Variable Properties).
If the referenced property is not
defined or if there does not exist a propertyAlias to associate the property
with the referenced variable then the semantics of the process is
undefined.
This sentence in bold was introduced with the
acceptance of Issue 145. The line should be changed to the
following:
If the referenced property is not defined, if
there does not exist a propertyAlias to associate the property with the
referenced variable or if the given property definition selects a node set of
a size other than one, then the standard fault bpws:selectionFailure MUST be
thrown by a compliant implementation.
#3 undefined changes to
bpws:missingRequest
10.4 Providing Web Service Operations
(Paragraph beginning with "The correlation between
a request and the corresponding reply…)
…For the purposes of this constraint, an onMessage
clause in a pick is equivalent to a receive (see Pick).
Moreover, a reply activity must always
be preceded by a receive activity for the same partner link, portType and
(request/response) operation, such that no reply has been sent for that
receive activity. The semantics of a process in which this constraint is
violated is undefined.
Strike the last two sentences since the
bpws:missingRequest fault is detailed a few paragraphs later.
Next in thread →
Next in month →