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: 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.


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