[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 82.3 - Missing Section
Hi,
can someone please send me a word doc copy :) thanks!
Rania
Alex Yiu wrote:
>
> Yes, let's do it word. Similar to the word-email-chain that we did in
> other chapter before.
>
> Say, Rania (started the document) => Danny => Alex => anybody else?
>
> Then, we may hold a 30 mins conf call or so to wrap that up.
>
> Thanks!
>
> Regards,
> Alex Yiu
>
>
> Danny van der Rijn wrote:
>
>> 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
>>> >>
>>> >>
>>>
>>>
>> ---------------------------------------------------------------------
>> 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]