[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: 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:30:39 -0400
From: Rania Khalaf <rkhalaf@watson.ibm.com>
To: Monica J Martin <Monica.Martin@Sun.COM>
References: <42E13A1E.20609@watson.ibm.com>
<42E69271.2070308@oracle.com> <42E79D5A.2040007@sun.com>
Hi Monica,
I think there is confusion here between the omission-shortcut in the
base and the completions.
The text you site below is about the omission-shortcut in the base: What
can I omit from a complete abstract BPEL that is otherwise required by
the XML Schema
In the completions section, we talk about what you add to an abstract
process to create the executables whose semantics it represents. The
latter must always include replacing opaque tokens (including those
omitted by omission-shortcut above) and may do more (see text on
completions definition in 82 proposal).
In the completions section, I say one cannot omit an interaction
activity that is in the abstract process when creating hte executable.
So,
If I have an AP:
<process>
<partnerLink .../>
<sequence>
<receive ../>
<invoke .. />
<reply ../>
</sequence>
</process>
An EP that has a sequence that removes the middle invoke, or uses
enclosure in a flow and links to effectively make sure it will never
ever happen, is not a valid executable completion.
As alex says, though, there may be deeper issues here that need further
clarification.
Regarding the example on replacing with empty regarding changing the
order, my proposal only talks about the order of interaction activities
in the AP. An opaque activity is not an interaction activity in the AP.
Finally, the last paragraph you quote is in fact in the proposal :) it's
just moved to the top bullet so sorry about making it hard to find ! The
addition on joins is in the completions section and not in the syntax
section. I don't think the two conflict, but perhaps I am missing
something .
The new sentences on the join condition are new. I noticed that there is
a problem that the old text did not allow one to add links in a valid EP
completion which I find too restrictive.
I hope I have addressed all ur concerns. please let me know if i have
missed anything.
Regards,
Rania
Monica J Martin wrote:
> 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.
>
>
> ---------------------------------------------------------------------
> 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]