wsbpel-spec-edit message

Subject: Re: [wsbpel-spec-edit] RE: Issue 82.1 - Resolution

From: Alex Yiu <alex.yiu@oracle.com>
To: Diane Jordan <drj@us.ibm.com>
Date: Mon, 13 Mar 2006 14:59:19 -0800

Hi,

The subject line is indeed a bit misleading. I also missed that email.
I guess I also need to look at that email closer.

Charlton, I attached that email archive HTML here, in case you don't have the web access.

Thanks!

Regards,
Alex Yiu

Diane Jordan wrote:

Charlton,
See this email for an explanation of the editing - http://www.oasis-open.org/apps/org/workgroup/wsbpel-spec-edit/email/archives/200602/msg00045.html
The subject was misleading so you may have missed it. There were no replies to it that I've seen or objections on the calls, but if that doesn't mean we can't still fix it if need be.
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

"Charlton Barreto" <cbarreto@adobe.com>
03/13/2006 05:15 PM

To
<wsbpel-spec-edit@lists.oasis-open.org>

cc
<CBARRETO@adobe.com>

Subject
[wsbpel-spec-edit] RE: Issue 82.1 - Resolution

Reviewing the latest spec in CVS, I saw that the changes for Issue 82.1 were for the most part incorporated. However, there was one place where I had a question:

Section 13.4.3, paragraph 3 reads:

“All start activities MUST be defined in a process of this Template Profile. This implies that NO new start activity (that is a message inbound activity annotated with a createInstance=”yes” attribute) is allowed to be added during executable completion. The Template Profile introduces a new “template”createInstance” attributed for use with opaque activities, since the standard “createInstance” attribute defined in the common abstract process schema is not allowed on opaque activities.”

Why was the second sentence (“The Template Profile introduces….”) added? It is redundant since we’ve already covered this concept earlier in Section 13.4.

The paragraph should read (conforming to our accepted resolution of Issue 82.1):

“All start activities MUST be defined in a process of this Template Profile. This implies that NO new start activity is allowed to be added during executable completion (that is, a message inbound activity annotated with a createInstance=”yes” attribute).

Best,

-Charlton.
--
Adobe Systems Incorporated
+1 (408) 536-4496 p
cbarreto@adobe.com

From: Charlton Barreto
Sent: Wednesday, 15 February 2006 14:54
To: 'wsbpel-spec-edit@lists.oasis-open.org'
Subject: Issue 82.1 - Resolution

Attached is a zip archive (change the extension to .zip to expand) of the spec text, based on a clean snapshot of the latest draft, containing my approved resolution for Issue 82.1 with Rania’s amendment.

Please let me know if you have any questions.

-Charlton.
--

Charlton Barreto
Sr .Computer Scientist
Adobe Systems Incorporated
345 Park Avenue, MS E15
San Jose, CA 95110-2704 USA
408.536.4496 p
415.692.5396 v
cbarreto@adobe.com

Title: Fw: [wsbpel] Issue 244 - Proposal for Vote

wsbpel-spec-edit message

Subject: Fw: [wsbpel] Issue 244 - Proposal for Vote

From: Francisco Curbera <curbera@us.ibm.com>
To: <wsbpel-spec-edit@lists.oasis-open.org>
Date: Mon, 27 Feb 2006 21:31:55 -0500

Seems like I responded to the wrong mail and this one ended up in the
general list, my apologies. Hre it goes again so you can get it in the
right mail folder :-)

Paco
----- Forwarded by Francisco Curbera/Watson/IBM on 02/27/2006 09:30 PM
-----

Francisco
Curbera/Watson/IB To: Dieter Koenig1 <dieterkoenig@de.ibm.com>
M@IBMUS cc: wsbpel@lists.oasis-open.org, Rania Khalaf/Watson/IBM@IBMUS,
cbarreto@adobe.com
02/27/2006 05:40 Subject: Re: [wsbpel] Issue 244 - Proposal for Vote
PM

I completed the edit of 82.1. The pen goes to Vinky.

I made a small to the resolution in the following paragraph, in Section
13.4.3. To the original paragraph Charlton had added a "template" prefix in
front of the "createInstance" attribute, so the resolution text read as
follows:

------------
All start activities MUST be defined in a process of this Template Profile.
This implies that NO new start activity is allowed to be added during
executable completion (that is a message inbound activity annotated with a
template:createInstance="yes" attribute).
------------

Nowhere else in the text is introduced or mentioned the
"template:createInstance" attribute; there is no explanation of why a
different createInstance is needed. This is not right from the readability
and completeness points of view. It will also make makes the paragraph
above sound really mysterious to uninitiated public. I have replaced the
text above by the following, which seems to convey the appropriate meaning
much more explicitly:

------------
All start activities MUST be defined in a process of this Template Profile.
This implies that NO new start activity (that is a message inbound activity
annotated with a createInstance="yes" attribute) is allowed to be added
during executable completion. The Template Profile introduces a new
"template:createInstance" attribute for use with opaque activities, since
the standard "createInstance" attribute defined in the common abstract
process schema is not allowed on opaque activities.
------------

Note that I changed two things:

1. I removed the "template" prefix from the phrase in parenthesis, since
its use is yet completely unexplained; it also seems actually inaccurate
(are startable activities with regular createInstance attributes allowed? I
don't think so).

2. I have added a note explaining the fact that a template:createInstance
attribute is being introduced to support <opaque>.

If I am wrong in my interpretation of the resolution in this particular
aspect, please let me know. I have copied Rania and Charlton since they
were directly involved in the drafting the resolution. In any case, I have
committed the spec so the editing process can proceed; we can always go
back and tweak this paragraph if we conclude that my text is not accurate.

Paco

Dieter Koenig1

<dieterkoenig@de. To:
wsbpel@lists.oasis-open.org

ibm.com> cc:

Subject: [wsbpel] Issue 244
- Proposal for Vote
02/27/2006 10:31

In order to fix the definition of bpws:conflictingRequest, and remove
bpws:invalidReply in favor of bpws:missingRequest, I propose the following
changes to the spec.

Note that all remaing references to the tuple (partner link, port type,
operation, correlation set) - dealing with bpws:conflictingReceive - are
correct.

----------------
(1) Section 10.4 - paragraph 10 - wrong text:
The correlation between a request and the corresponding reply is based on
the constraint that more than one outstanding synchronous request from a
specific partner link for a particular portType, operation and correlation
set(s) MUST NOT be outstanding simultaneously. If this constraint is
violated during execution, then the standard fault bpws:conflictingRequest
MUST be thrown by a conforming implementation. Note that this is
semantically different from the bpws:conflictingReceive, because it is
possible to create the conflictingRequest by consecutively receiving the
same request on a specific partner link for a particular portType,
operation and correlation set(s). For the purposes of this constraint, an
onMessage clause in a pick is equivalent to a receive (see Pick).

Action - drop this text from paragraph (paragraph 15 already explains
bpws:conflictingRequest correctly). The text starting with "Moreover, ..."
remains.

----------------
(2) Section 10.4 - paragraph 12 - wrong text:
If a reply activity is being carried out during the execution of a business
process instance and no synchronous request is outstanding for the
specified partnerLink, portType, operation and correlation set(s), then the
standard fault bpws:invalidReply MUST be thrown by a conforming
implementation.

Action - drop this paragraph completely (paragraph 16 already explains it
correctly using bpws:missingRequest).

----------------
(3) Appendix A. - wrong text (table row explaining conflictingRequest):
Thrown when more than one synchronous inbound request on the same partner
link for a particular port type, operation and correlation set(s) are
active.

Action - replace with new text (table row explaining conflictingRequest):
Thrown when more than one synchronous inbound request on the same partner
link, operation and message exchange are active.

----------------
(4) Appendix A. - wrong text (table row explaining invalidReply):
Thrown when a reply is sent on a partner link, portType and operation for
which the corresponding receive with the same correlation has not been
carried out.

Action - drop this row completely (bpws:missingRequest is sufficient).

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

Follow-Ups:
- RE: [wsbpel-spec-edit] RE: Issue 82.1 - Resolution
  - From: "Charlton Barreto" <cbarreto@adobe.com>

References:
- Re: [wsbpel-spec-edit] RE: Issue 82.1 - Resolution
  - From: Diane Jordan <drj@us.ibm.com>