[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] State of variables following bpel:invalidVariables fault
FYI - I changed the order of the paragraphs in bold (third and fourth
paragraphs in case the formatting is lost).
In the current draft of the spec, the order is
reversed. From: Mark Ford [mailto:mark.ford@active-endpoints.com] Sent: Thursday, March 30, 2006 4:54 PM To: 'Alex Yiu' Cc: wsbpel@lists.oasis-open.org Subject: RE: [wsbpel] State of variables following bpel:invalidVariables fault Switching the order of the paragraphs would make this clearer - at least
to me.
Here are the paragraphs in context:
The optional keepSrcElementName attribute of the <copy> construct is used to specify
whether the element name of the destination (as selected by the to-spec) will be
replaced by the element name of the source (as selected by the from-spec) during
the copy operation. See section 8.4.1, Replacement Logic of Copy Operations.
The optional validate attribute can be used with the <assign> activity. When validate is set to "yes", the <assign> activity validates all the variables being
modified by the activity. A WS-BPEL implementation MAY provide a mechanism to
turn on/off any explicit validation. E.g. validate attribute at assign. If the "validate" part of the assign activity fails, that is, one of
the variables is invalid against its correponding XML definition, a standard
fault of "bpel:invalidVariables" fault MUST be thrown. If there is any fault during the execution of an assignment activity
the destination variables MUST be left unchanged, as they were at the start of
the activity (as if the assign activity were atomic). This applies regardless of
the number of assignment elements within the overall assignment activity.
The assign activity MUST be executed as if, for the duration of its
execution, it was the only activity in the process being executed.
From: Alex Yiu [mailto:alex.yiu@oracle.com] Sent: Thursday, March 30, 2006 4:11 PM To: Mark Ford Cc: wsbpel@lists.oasis-open.org; Alex Yiu Subject: Re: [wsbpel] State of variables following bpel:invalidVariables fault Mark, The way that I read is: yes the "bpel:invalidVariables" fault (just like any fault happens during <assign>, e.g. selectionFailure ) will revert variables back to original state before the execution of <assign>. The current text is relatively clear to me. If other people think the text is still unclear, please feel free to voice suggested clarification text. Regards, Alex Yiu Mark Ford wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]