OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue 82.1 - question on editing



Resending with correct subject so issues list will stay current.  
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

----- Forwarded by Diane Jordan/Raleigh/IBM on 02/27/2006 06:12 PM -----
Francisco Curbera/Watson/IBM@IBMUS

02/27/2006 05:40 PM

To
Dieter Koenig1 <dieterkoenig@de.ibm.com>
cc
wsbpel@lists.oasis-open.org, Rania Khalaf/Watson/IBM@IBMUS, cbarreto@adobe.com
Subject
Re: [wsbpel] Issue 244 - Proposal for Vote





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                                                                                                  
                     AM                                                                                                                
                                                                                                                                       




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




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