Hi Rania,
Regarding to your high level proposal on Issue 82.3, here are some
high-level comments so far:
- Minor comments:
- 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)
- 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:
- IMHO, I tend to think we should NOT bar the usage of $variable
(i.e.
getVariableData() equivalence) in AP11 profile
- 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.)
- 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
|