Title: Re: [wsbpel] Issue 82.3 - Missing Section
Should we do it in Word?
Rania Khalaf wrote:
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
>>
>>
