Re: [wsbpel] Issue - 82.3 - Proposal for vote

[Monica J Martin <Monica.Martin@Sun.COM>]

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.