[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 82.3 - Missing Section
Hi guys,
I can't follow the edits like this, and would rather we just do the
usual phone editing.
thanks,
Rania
Danny van der Rijn wrote:
> I agree that the statement about declaration overriding is normative,
> and not editing. But it needs to be said, doesn't it?
>
> As for the "illegal" word - doesn't the sentence before ("MUST NOT...")
> outlaw it?
>
> Alex Yiu wrote:
>
>>
>>
>> Hi,
>>
>> My comments on top of Rania's and Danny's text are listed below in
>> *BLUE*:
>>
>> --------------------------
>>
>>
>> Subset of the Executable Completions Allowed in the Base
>>
>> With respect to executable BPEL completions of an abstract process
>> that uses this profile, the intent of the profile requires a valid
>> completion to follow the same interactions as the abstract process,
>> with the partners that are specified by the abstract process. The
>> executable process may, however, perform additional interaction steps
>> relating to other partners.
>>
>>
>>
>> _In order to achieve the intent of the profile, _Therefore: a
>> completion MUST NOT change the presence or order of interactions
>> already in the abstract process, and it MUST NOT perform additional
>> interactions with the partner links defined in the abstract process.
>> It is important to observe that oOne such illegal [AYIU: I am not sure
>> "illegal" is the right word here ... Because, this profile does not
>> exactly outlaw it. I would suggest to say just "One way"] way in which
>> that the order of interactions can could be modified is by changing
>> the value of a variable used in a condition that affects branching.
>> The condition could be changed in such a way that the new so that the
>> new effective branching behavior is in direct conflict with what is
>> specified by the abstract process. Conditions that affect the flow of
>> control such as transition conditions, “if-then” or “while”
>> expressions, among others, can have such an effect on the order of
>> interactions. For example, adding a new <while> loop with a “true”
>> condition as a child of an existing <sequence> would hang the process.
>> This profile does not normatively disallow such actions, as it would
>> be too restrictive. However, the intent of this advisory note should
>> be followed. In this profile, we will not restrict writing to
>> variables in a strict manner, but provide this note as an advisory
>> restriction.
>>
>>
>>
>> The possible locations of new activities are not explicitly defined in
>> this profile. Activities may be added anywhere that the Executable
>> Completions definition (not Basic) allows, where completions to the
>> base are allowed, as long as the restrictions enumerated below are
>> followed. In this profile, the valid executable completions of an
>> abstract process are obtained through both 'opaque token replacement'
>> and 'addition of BPEL constructs', with the following restrictions:
>>
>>
>>
>> · New activities (including those created to replace opaque
>> activities) MUST NOT interact with refer to partnerLinks already
>> defined in the abstract process. This rule does not affect adding
>> interactions with new partnerLinks present in the executable
>> completion but not in the abstract process. New partnerLink
>> declarations that would hide existing ones, thereby changing the
>> partnerLink to which an existing activity refers MUST NOT be used.
>>
>>
>>
>> · vdRNOTE: This bullet is completely subsumed by the one
>> before. Remove it or add it as a note to the previous. [AYIU: agree
>> with Danny here. Merging it as an elaboration note to the above bullet
>> seems make it flow better.] The endpoint reference of any partnerLink
>> defined in the abstract process MUST NOT be modified (whether using an
>> <assign> activity or otherwise). Additionally, an endpoint reference
>> of any partnerLink defined in the abstract process MUST NOT be copied
>> into the reference of a newly created partnerLink. The reason is that
>> the former would effectively prevent subsequent interactions with that
>> partner and the latter would add new ones. Remember that 'opaque
>> token replacement' also replaces opaque tokens omitted through the
>> omission-shortcut.
>>
>> · New variable declarations that would hide existing ones,
>> thereby changing the branching behavior MUST NOT be used. [AYIU: This
>> is a normative change here. I am not sure this fits the original
>> intent of this profile.]
>>
>> · vdRNOTE: Moved from below. Executable completions MUST NOT add new
>> links targeting an existing activity that exists in the abstract
>> process. Adding such a new link would have the effect of changing the
>> corresponding join condition, which is in violation of the completion
>> rules of the base (since it modifies a non-opaque existing value).
>> This restriction does not affect the addition of links to new
>> activities that are not replacing opaque activities.
>>
>>
>>
>> · The lexical parent of an existing BPEL construct (including
>> activities in particular) present in the abstract process MUST NOT be
>> changed in an valid executable completion. Hence, the nesting
>> structure of composite activities around any activity in an abstract
>> process MUST remains unchanged in any legal completion. Some examples
>> to illustrate this restriction are provided below. The word ‘existing’
>> is used in the examples to refer to constructs defined in the abstract
>> process from which the executable completions are being created:
>>
>> o Examples of legal additions:
>>
>> § Adding a variable or a partner link to an existing scope S,
>> even though that scope is the parent of existing activity A, except as
>> disallowed above.
>>
>> § Adding a new link def to an existing flow, except as
>> disallowed above
>>
>> o Examples of illegal additions:
>>
>> § Adding a <while> activity around the existing activity A
>> whose parent is another existing activity B. vdRNOTE: if A exists,
>> it already must have an existing parent B
>>
>> § Adding a new scope around an existing variable definition
>> whose parent is an existing scope S. vdRNOTE: as above.
>>
>>
>>
>> · A valid executable completion MUST NOT add:
>>
>> o New branches to an existing “if-then-else” activity, unless it
>> has no “else” branch, and the new branch is added after all existing
>> branches.
>>
>> o New branches to an existing pick activity.
>>
>> o New fault, compensation, or termination handlers to an
>> existing scope. However, they may be added at the process level.
>>
>> o <exit> activities.
>>
>>
>>
>> · Activities that throw non-standard faults (i.e. (e.g.?) web
>> service activities whose operations define faults, <throw>) MAY be
>> added only if the exception will not be propagated outside of the
>> highest /newly added/ ancestor of the fault-throwing activity to any
>> existing activity. For example, consider adding an activity A as a
>> child of an existing sequence S. Then, one may only add a <throw>
>> within A if the fault it throws does not reach the scope of the
>> existing sequence S. In other words, the fault must be caught and
>> fully handled by A or its descendants, and not be re-thrown by them.
>>
>>
>>
>> vdrNOTE: moved to above. Observe that eExecutable completions MUST
>> NOT add new links targeting an existing activity that exists in the
>> abstract process. Adding such a new link would have the effect of
>> changing the corresponding join condition, which is in violation of
>> the completion rules of the base (since it modifies a non-opaque
>> existing value). This restriction does not affect the addition of
>> links to new activities that are not replacing opaque activities.
>>
>> --------------------------
>>
>> Thanks!
>>
>> Regards,
>> Alex Yiu
>>
>>
>> Danny van der Rijn wrote:
>>
>>> My suggestions for edits are in green below.
>>>
>>> Rania Khalaf wrote:
>>>
>>>> Hi,
>>>>
>>>> A section was mistakenly dropped from the 82.3 resolution. I am
>>>> attaching it below, with some minor editing fixes (track changes is
>>>> on).
>>>>
>>>> I am also adding it to the docs list on the web page and here is the
>>>> link to it.
>>>>
>>>> http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18359/82.3-lost-section.htm
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Subset of the Executable Completions Allowed in the Base
>>>>
>>>> With respect to executable BPEL completions of an abstract process
>>>> that uses this profile, the intent of the profile requires a valid
>>>> completion to follow the same interactions as the abstract process,
>>>> with the partners that are specified by the abstract process. The
>>>> executable process may, however, perform additional interaction
>>>> steps relating to other partners.
>>>>
>>>>
>>>>
>>>> Therefore: a completion MUST NOT change the presence or order of
>>>> interactions already in the abstract process, and it MUST NOT
>>>> perform additional interactions with the partner links defined in
>>>> the abstract process. It is important to observe that oOne such
>>>> illegal way in which that the order of interactions can could be
>>>> modified is by changing the value of a variable used in a condition
>>>> that affects branching. The condition could be changed in such a way
>>>> that the new so that the new effective branching behavior is in
>>>> direct conflict with what is specified by the abstract process.
>>>> Conditions that affect the flow of control such as transition
>>>> conditions, “if-then” or “while” expressions, among others, can have
>>>> such an effect on the order of interactions. For example, adding a
>>>> new <while> loop with a “true” condition as a child of an existing
>>>> <sequence> would hang the process. This profile does not normatively
>>>> disallow such actions, as it would be too restrictive. However, the
>>>> intent of this advisory note should be followed. In this profile,
>>>> we will not restrict writing to variables in a strict manner, but
>>>> provide this note as an advisory restriction.
>>>>
>>>>
>>>>
>>>> The possible locations of new activities are not explicitly defined
>>>> in this profile. Activities may be added anywhere that the
>>>> Executable Completions definition (not Basic) allows, where
>>>> completions to the base are allowed, as long as the restrictions
>>>> enumerated below are followed. In this profile, the valid executable
>>>> completions of an abstract process are obtained through both 'opaque
>>>> token replacement' and 'addition of BPEL constructs', with the
>>>> following restrictions:
>>>>
>>>>
>>>>
>>>> · New activities (including those created to replace opaque
>>>> activities) MUST NOT interact with refer to partnerLinks already
>>>> defined in the abstract process. This rule does not affect adding
>>>> interactions with new partnerLinks present in the executable
>>>> completion but not in the abstract process. New partnerLink
>>>> declarations that would hide existing ones, thereby changing the
>>>> partnerLink to which an existing activity refers MUST NOT be used.
>>>>
>>>>
>>>>
>>>> · vdRNOTE: This bullet is completely subsumed by the one
>>>> before. Remove it or add it as a note to the previous. The
>>>> endpoint reference of any partnerLink defined in the abstract
>>>> process MUST NOT be modified (whether using an <assign> activity or
>>>> otherwise). Additionally, an endpoint reference of any partnerLink
>>>> defined in the abstract process MUST NOT be copied into the
>>>> reference of a newly created partnerLink. The reason is that the
>>>> former would effectively prevent subsequent interactions with that
>>>> partner and the latter would add new ones. Remember that 'opaque
>>>> token replacement' also replaces opaque tokens omitted through the
>>>> omission-shortcut.
>>>>
>>> · New variable declarations that would hide existing ones,
>>> thereby changing the branching behavior MUST NOT be used.
>>>
>>> · vdRNOTE: Moved from below. Executable completions MUST NOT add
>>> new links targeting an existing activity that exists in the abstract
>>> process. Adding such a new link would have the effect of changing the
>>> corresponding join condition, which is in violation of the completion
>>> rules of the base (since it modifies a non-opaque existing value).
>>> This restriction does not affect the addition of links to new
>>> activities that are not replacing opaque activities.
>>>
>>>>
>>>>
>>>> · The lexical parent of an existing BPEL construct (including
>>>> activities in particular) present in the abstract process MUST NOT
>>>> be changed in an valid executable completion. Hence, the nesting
>>>> structure of composite activities around any activity in an abstract
>>>> process MUST remains unchanged in any legal completion. Some
>>>> examples to illustrate this restriction are provided below. The word
>>>> ‘existing’ is used in the examples to refer to constructs defined in
>>>> the abstract process from which the executable completions are being
>>>> created:
>>>>
>>>> o Examples of legal additions:
>>>>
>>>> § Adding a variable or a partner link to an existing scope
>>>> S, even though that scope is the parent of existing activity A,
>>>> except as disallowed above.
>>>>
>>>> § Adding a new link def to an existing flow, except as
>>>> disallowed above
>>>>
>>>> o Examples of illegal additions:
>>>>
>>>> § Adding a <while> activity around the existing activity A
>>>> whose parent is another existing activity B. vdRNOTE: if A exists,
>>>> it already must have an existing parent B
>>>>
>>>> § Adding a new scope around an existing variable definition
>>>> whose parent is an existing scope S. vdRNOTE: as above.
>>>>
>>>>
>>>>
>>>> · A valid executable completion MUST NOT add:
>>>>
>>>> o New branches to an existing “if-then-else” activity, unless
>>>> it has no “else” branch, and the new branch is added after all
>>>> existing branches.
>>>>
>>>> o New branches to an existing pick activity.
>>>>
>>>> o New fault, compensation, or termination handlers to an
>>>> existing scope. However, they may be added at the process level.
>>>>
>>>> o <exit> activities.
>>>>
>>>>
>>>>
>>>> · Activities that throw non-standard faults (i.e. (e.g.?) web
>>>> service activities whose operations define faults, <throw>) MAY be
>>>> added only if the exception will not be propagated outside of the
>>>> highest /newly added/ ancestor of the fault-throwing activity to any
>>>> existing activity. For example, consider adding an activity A as a
>>>> child of an existing sequence S. Then, one may only add a <throw>
>>>> within A if the fault it throws does not reach the scope of the
>>>> existing sequence S. In other words, the fault must be caught and
>>>> fully handled by A or its descendants, and not be re-thrown by them.
>>>>
>>>>
>>>>
>>>> vdrNOTE: moved to above. Observe that eExecutable completions MUST
>>>> NOT add new links targeting an existing activity that exists in the
>>>> abstract process. Adding such a new link would have the effect of
>>>> changing the corresponding join condition, which is in violation of
>>>> the completion rules of the base (since it modifies a non-opaque
>>>> existing value). This restriction does not affect the addition of
>>>> links to new activities that are not replacing opaque activities.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>---------------------------------------------------------------------
>>>>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
>>>>
>>> ---------------------------------------------------------------------
>>> 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]