[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
The purpose of a join condition is to "join", i.e. synch-up threads of work that are going on in parallel. The purpose of a start condition is to specify under which conditions (causal, temporal,...) an activity that is known to be ready to be performed will actually be performed. If there is nothing to join or sync-up, a join condition doesn't make sense at all. Thus, we should not introduce an artificial join condition for activities without incoming edges (even if this condition would so trivial to handle than a constant TRUE condition). Regards, Frank ------------------- Prof. Dr. Frank Leymann, Distinguished Engineer IBM Software Group Member, IBM Academy of Technology Phone 1: +49-7031-16 39 98 Phone 2: +49-7056-96 50 67 Mobile: +49-172-731 5858 -------------------- Please respond to <a class="moz-txt-link-rfc2396E" href="mailto:ygoland@bea.com"><ygoland@bea.com></a> To: Frank Leymann/Germany/IBM@IBMDE, <a class="moz-txt-link-rfc2396E" href="mailto:wsbpel@lists.oasis-open.org"><wsbpel@lists.oasis-open.org></a> cc: Subject: RE: [wsbpel] Issue - 74 - Ambiguity in join condition definition There are two cases where an activity does not have any incoming links: Case 1 - No Join Condition is Explicitly Defined - This is a hole. The spec requires that the join condition be equal to the OR join of the incoming links but there are no incoming links so what does it mean to have an OR join of nothing? Tri-state logic being more than I want to deal with I suspect a quick sentence of the form "in the case where an explicit join condition is not defined and the activity does not have any incoming links the value of the join condition is set to true." Case 2 - A Join Condition is Explicitly Defined - In this case the only function that can be called is getLinkStatus and that can only be called on links that have the activity as their target. By definition of this scenario there is no such link therefore any call to getLinkStatus will produce a static analysis error (we need to add this to the static analysis error list). Therefore the only contents of the Join Condition can be various types of fancy Boolean nonsense all based on playing around with True and False. While silly, it isn't harmful. Therefore I would propose that we pretend that join conditions exist on all activities, independent of having any links pointing at them. In the case where there are no links and no explicitly defined join condition we just a-priori define the join condition to be true. All other cases seem to take care of themselves. Just a thought, Yaron </pre> <blockquote type="cite"> <pre wrap="">-----Original Message----- From: Frank Leymann [<a class="moz-txt-link-freetext" href="mailto:LEY1@de.ibm.com">mailto:LEY1@de.ibm.com</a>] Sent: Tuesday, October 21, 2003 12:50 AM To: <a class="moz-txt-link-abbreviated" href="mailto:wsbpel@lists.oasis-open.org">wsbpel@lists.oasis-open.org</a> Subject: RE: [wsbpel] Issue - 74 - Ambiguity in join condition definition The current spec says: "If the explicit joinCondition is missing, the implicit condition requires the status of at least one incoming link to be positive..." I.e. if you don't specify any explicit join condition the implicit condition is the ORing of the truth values of the incoming links. Furthermore, the current spec says that "The expression for a join condition for an activity MUST be constructed using only Boolean operators and the bpws:getLinkStatus function (see Expressions) applied to incoming links at the activity" I.e. it is NOT possible to spec join conditions that refer to other functions than getLinkStatus. To avoid "mathematical subtleties" that can blow your mind (statements about the empty set...), we need an explicit clarification for situations where there are no incoming links at all. Regards, Frank -------------------- Please respond to <a class="moz-txt-link-rfc2396E" href="mailto:ygoland@bea.com"><ygoland@bea.com></a> To: <a class="moz-txt-link-rfc2396E" href="mailto:wsbpel@lists.oasis-open.org"><wsbpel@lists.oasis-open.org></a> cc: Subject: RE: [wsbpel] Issue - 74 - Ambiguity in join condition definition What is harmed if we allow join conditions on activities that don't have links? Isn't it already possible to write a join condition that doesn't refer to any form of link state in calculating its Boolean output? Just Curious, Yaron -----Original Message----- From: ws-bpel issues list editor </pre> </blockquote> <pre wrap=""><!---->[<a class="moz-txt-link-freetext" href="mailto:peter.furniss@choreology.com">mailto:peter.furniss@choreology.com</a>] Sent: Thursday, October 09, 2003 2:59 PM To: <a class="moz-txt-link-abbreviated" href="mailto:wsbpel@lists.oasis-open.org">wsbpel@lists.oasis-open.org</a> Subject: [wsbpel] Issue - 74 - Ambiguity in join condition definition This issue has been added to the wsbpel issue list. The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent document with the title in the "Issues" folder of the WSBPEL TC document list - the next posting will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL. Issue - 74 - Ambiguity in join condition definition Status: open Date added: 9 Oct 2003 Submitter: Dieter Roller Date submitted: 09 October 2003 Description: The specs could possibly be interpreted in such a way that activities without an incoming link could also have a join condition. This is not the intended meaning. Submitter's proposal: Modify the first sentence in the second paragraph in section 12.5.1 as follows : Every activity that is the target of a link has an implicit or explicit joinCondition attribute associated with it; an activity that is not target of a link has no joinCondition attribute associated with it. Furthermore it may be helpful to have a similar sentence earlier in the document. Changes: 9 Oct 2003 - new issue To comment on this issue, please follow-up to this announcement on the <a class="moz-txt-link-abbreviated" href="mailto:wsbpel@lists.oasis-open.org">wsbpel@lists.oasis-open.org</a> list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 74 - [anything]" or is a reply to such a message. To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement). To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to <a class="moz-txt-link-freetext" href="http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup">http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup</a> . php . To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to <a class="moz-txt-link-freetext" href="http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup">http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup</a> . php. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to <a class="moz-txt-link-freetext" href="http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php">http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php</a>. </pre> </blockquote> </body> </html> --------------050903030208040607060102--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]