[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 82.3 - Proposal for vote
Rania, Alex has brought up some good points and raises some questions about the concept proposal. It also raised my attention to the agreements with the side group members and what eventually was posted. See inline. > yiu: 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) > mm1: Agree. > 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). > mm1 Agree. > * Major comments: > o IMHO, I tend to think we should NOT bar the usage of > $variable (i.e. getVariableData() equivalence) in AP11 profile > mm1: Rania, your proposal raised this as a question for discussion and clarification. Alex, this item should be discussed and decided. > 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. > mm1: Looking at the proposal sent to the list Rania, this is inconsistent with the text that I believe you proposed to the side group. Originally the omission was to replace opaque tokens only where the XML schema required it. The proposal published to the list and that was agreed to differ. List proposal....."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...." Side group discussion: "the omission-shortcut applies only to items that would otherwise be required *by the XML schema* (example: activity in a fault handler)...." > + 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) > mm1: In the original concept proposals (such as those with the side group), I thought we allowed for opaque entity (such as activity) to be empty which is the case where you effectively omit in in the executable completion. There is support for that in the Issue 82 language: ..."a) Opaque Token Replacement: Replacing every opaque token (including those omitted using the omission-shortcut above) with a corresponding executable token. For example, replacing an opaque activity with an <empty>." Therefore, I think we should consider Alex's suggestion. > + 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.) > mm1: When you fill in an opaque entity, effectively delete it with an empty, etc. that in essence can change the order. Add could have the similar results. Agree we should consider Alex's suggestion. > 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.) > mm1: This comment about join conditions was added in the latest renditions 15 and 22 July 2005 and, to my knowledge, doesn't reflect what was discussed in the side group. Here is what I had thought was the language proposed (before sent to the list): "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." Therefore, I think we should discuss these changes and how to move forward. Thanks.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]