[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 82.3 - Proposal for vote]
-------- Original Message -------- Subject: Re: [wsbpel] Issue - 82.3 - Proposal for vote Date: Wed, 27 Jul 2005 12:16:28 -0400 From: Rania Khalaf <rkhalaf@watson.ibm.com> To: Alex Yiu <alex.yiu@oracle.com> References: <42E13A1E.20609@watson.ibm.com> <42E69271.2070308@oracle.com> Hi Alex, thanks for you comments. regarding the minor comments, good catch :) thanks! regarding the major comments, I also agree with allowing getVariableData. That is my preference too. regarding the rest, I agree it is good to clarify and appreciate the discussion. I will need little more time to draft a response here and will get back to you. regards rania Alex Yiu wrote: > > Hi Rania, > > Regarding to your high level proposal on Issue 82.3, here are some > high-level comments so far: > > * Minor comments: > o Changing the URI from schemas.xmlsoap.org based to > urn:oasis: based. E.g.We have updated the default expression > language URI to > "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0" as the > resolution of Issue 165. > (http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue165) > o Apart from "variable", "inputVariable" and "outputVariable", > similar semantics applied to "fromPart" and "toPart" (those > are added after a Yaron's proposal was passed in Germany). > > > * Major comments: > o IMHO, I tend to think we should NOT bar the usage of > $variable (i.e. getVariableData() equivalence) in AP11 profile > o Regarding to_ partnerLink communication_, Rania's proposal > states that executable completion should not "add", "omit", > or "change the order". I agree on "add" part. However, it is > not so feasible to enforce the disallowance of "omit" and > "change the order" is bit under-defined. > + For "omit", filling in the opaque expression condition > in <while>, <switch>/<if> or transitionCondition of > control-links and adding <exit> / <throw> activity can > effectively omit certain partnerLink communication. > (There is no general infinite loop detection algorithm > for a Turing-complete language, AFAIK) > + For "change-the-order", depending its detailed > definition of "change-the-order", adding a control > link can change the order in a sense? Therefore, we > need to clarify what "change-the-order" mean. A > different term may be better (e.g. execution > completion should NOT "conflict with any explicit > (control dependency) order" defined in AP.) > o About adding new control-links, the restriction of the > join-condition changes relatively seems arbitary. How about > using "not" with the new join-condition? Instead of > restricting the change in join-conditions, we may want to > think about whether to disallow adding new links with an > activity existing in AP as target, during execution > completion. (Adding a "never-fire" link can be a way to > "omit" certain activity and communications.) > > > Thanks! > > > Regards, > Alex Yiu > > > > Rania Khalaf wrote: > >> >> >> -------- Original Message -------- >> Subject: Re: [wsbpel] Issue - 82.3 - Proposal for vote >> Date: Fri, 15 Jul 2005 16:44:20 -0400 >> From: Rania Khalaf <rkhalaf@watson.ibm.com> >> To: Rania Khalaf <rkhalaf@watson.ibm.com> >> CC: Monica J Martin <Monica.Martin@Sun.COM>, wsbpel@lists.oasis-open.org >> References: <42BC4975.1090107@watson.ibm.com> >> <42BC4F4A.4080907@tibco.com> <42BC51BC.5020005@watson.ibm.com> >> <42BC5FBE.8060400@oracle.com> <42C02C11.3010500@watson.ibm.com> >> <42C03FD1.90403@watson.ibm.com> <42C04EEC.3000003@sun.com> >> <42C0574D.10204@watson.ibm.com> <42C0583A.2010207@watson.ibm.com> >> >> Hi everyone, >> >> First phase of two-phase voting (content, then spec wording). I've >> merged the previously named 'proposed changes' section into the main >> text of this mail since this is the proposal. >> >> -------------------------------------------------- >> AP1.1 refactoring, start. >> ------------------------------- >> >> (add motivation in phase 2) >> >> (consider what old text to bring in from spec and how to modify it to >> introduce various aspects, especially regarding clarifications about >> initialization of correlation sets and variable omission in phase 2). >> >> ProfileURI: >> >> - http://schemas.xmlsoap.org/ws/2004/03/business-process/abstract/ap11 >> >> >> Base Language subset >> _____________________ >> >> .. This profile restricts the base in the following manner: >> >> * Allowing all expressions to be opaque except joinCondition. Please >> note that the joinCondition is based on the transition conditions on >> the incoming links. If the joinCondition is missing its default >> value is the disjunction of the status of the incoming links. >> >> * The only attributes that can be opaque are the attributes >> "variable", "inputVariable" and "outputVariable", on >> receive/invoke/reply/onMessage/onEvent (Note: bug fix based on Issue >> 97: fixing the consistency for elements onMessage and onEvent). >> >> * Allowing opaque activity, as a bug fix for the two reasons >> below. Note that its use elsewhere is superfluous since completions >> in this profile allow adding new BPEL activities anywhere: >> >> -Allows for hiding an activity that is the source or target of >> -links. Allows for using omission-shortcut in places like fault >> handlers etc (This had led to Issue 91). >> >> * It is not clear whether BPEL function 'getVariableData' is allowed >> (what's the new form of this with $ etc): Text disallows it, but >> example uses it. Need to vote on this. Preference is to disallow >> it. However, 'get VariablePropery' is still allowed. >> >> * Activity <exit > is not allowed. >> >> * Uses omission-shortcut for the opaque tokens above (allowed by all APs >> anyway). >> >> >> Base Completions subset >> _________________________ >> >> Places where new activities may be added are not explicitly defined in >> processes in this profile. The permitted executable completions of >> abstract processes in this profile include both 'Opaque Token >> Replacement' and 'Addition of BPEL Constructs', but subsetting those >> such that: >> >> o Each process that is a valid executable completion of a process in >> this profile MUST NOT: >> >> * add to >> * omit any of >> * or change the order (control dependency) of >> >> any of the interactions along the partnerlinks already defined in the >> abstract process, even if replacing opaque activities (including those >> omitted with omission-shortcut, such as activity of a fault >> handler). Note that this still allows for adding new interactions with >> new partnerLinks (ie: partnerLinks added in the executable completion >> but not present in the abstract process). >> >> o It is not allowed to add copies in assigns whose 'to' is any of the >> EPRs of the partnerLinks defined in the abstract process, because that >> is equivalent to removing subsequent interactions with that partner. >> Remember that 'opaque token replacement' also replaces opaque tokens >> omitted through the omission-shortcut. >> >> >> * In case new links are added in a completion to an activity in the >> abstract process itself, the join condition of the target activity >> can be modified but only by AND-ing or OR-ing the status of the new >> link with the original join condition defined in the abstract >> process. The addition of new links must not violate the first bullet >> above (regarding existing interactions) >> >> >> ( Note: The phrase 'even if .. ' sentence is pending whether opaque >> activities get allowed. ) >> >> >> --------------------------------------------------------------------- >> 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]