[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [wsbpel] Issue R1 Final Resolution
The final resolution for R1 was to accept the original proposal
from here: http://www.oasis-open.org/archives/wsbpel/200610/msg00070.html
with a slight rewording for Parts 1 and 4 provided by Danny. Here is the final text of the proposal: 1) Last
paragraph in Section 10.3 [SA00048]
When the optional inputVariable and outputVariable attributes are being used in an <invoke>
activity, the variables referenced by inputVariable and outputVariable MUST be messageType
variables whose QName matches the QName of the input and output message type
used in the operation, respectively, except as follows: if the WSDL operation
used in an <invoke> activity uses a message
containing exactly one part which itself is defined using an element, then a
variable of the same element type as used to define the part MAY be referenced
by the inputVariable and outputVariable attributes
respectively. The result of using a variable in the previously defined
circumstance MUST be the equivalent of declaring an anonymous temporary WSDL
message variable based on the associated WSDL message type. In the case of an inputVariable, the value of the variable referenced
by the attribute will be used to set the value of the part in the anonymous
temporary WSDL message variable. In the case of an outputVariable, the value of the received part in the temporary WSDL message variable
will be used to set the value of the variable referenced by the attribute. TO: (bold
text between *** and *** has been inserted. The asterisks are in case the bold
is lost in email and are not part of the final text) 2) First paragraph in Section 10.3.1 FROM: The <toParts> element provides an
alternative to explicitly creating multi-part WSDL messages from the contents
of WS-BPEL variables. By using the <toParts>
element, an anonymous temporary WSDL variable is declared based on the type
specified by the relevant WSDL operation's input message. The <toPart>
elements, as a group, act as the single virtual <assign>,
with each <toPart>
acting as a <copy>.
Each <copy>
operation copies data from the variable indicated in the fromVariable
attribute into the part of the anonymous temporary WSDL variable referenced in
the part
attribute of the <toPart> element (see section 8.4. Assignment).
The virtual <assign>
MUST follow the same semantics and use the same faults as a real <assign>.
[SA00050]
When <toParts>
is present in an <invoke>, it is not required to have a <toPart>
for every part in the WSDL message definition, nor is the order in which parts
are specified relevant. Parts not explicitly represented by <toPart>
elements would result in uninitialized parts in the target anonymous WSDL
variable used by the <invoke> or <reply>
activity. Such processes with missing <toPart> elements MUST be
rejected during static analysis. [SA00051]
The inputVariable
attribute MUST NOT be used on an <invoke> activity that
contains <toPart>
elements. TO: (bold
text between *** and *** has been inserted. The asterisks are in case the bold
is lost in email and are not part of the final text) The <toParts> element provides an
alternative to explicitly creating multi-part WSDL messages from the contents
of WS-BPEL variables. By using the <toParts>
element, an anonymous temporary WSDL variable is declared based on the type
specified by the relevant WSDL operation's input message. The <toPart>
elements, as a group, act as the single virtual <assign>,
with each <toPart>
acting as a <copy>.
Each <copy>
operation copies data from the variable indicated in the fromVariable
attribute into the part of the anonymous temporary WSDL variable referenced in
the part
attribute of the <toPart> element (see section 8.4. Assignment).
***If the <copy> operation is copying an element variable to an
element part then the keepSrcElementName option for the operation is set to
"yes".*** The virtual <assign> MUST follow the same
semantics and use the same faults as a real <assign>. [SA00050]
When <toParts>
is present in an <invoke>, it is not required to have a <toPart>
for every part in the WSDL message definition, nor is the order in which parts
are specified relevant. Parts not explicitly represented by <toPart>
elements would result in uninitialized parts in the target anonymous WSDL variable
used by the <invoke>
or <reply>
activity. Such processes with missing <toPart> elements MUST be
rejected during static analysis. [SA00051]
The inputVariable
attribute MUST NOT be used on an <invoke> activity that
contains <toPart>
elements. 3) 2nd paragraph from Section
10.3.1 FROM: The <fromPart> element is
similar to the <toPart>
element. The <fromPart>
element is used to retrieve data from an incoming multi-part WSDL message and
place it into individual WS-BPEL variables. When a WSDL
message is received on an <invoke> activity that uses <fromPart>
elements, the message is placed in an anonymous temporary WSDL variable of the
type specified by the relevant WSDL operation's output message. The <fromPart>
elements, as a group, act as a single virtual <assign>,
with each
<fromPart> acting as a <copy>.
Each <copy>
operation copies the data at the part of the anonymous temporary WSDL variable
referenced in the part attribute of the <fromPart>
into the variable indicated in the toVariable attribute. The virtual <assign>
MUST follow the same semantics and generate the same faults as a real <assign> (see
section 8.4. Assignment). When a <fromPart>
is present in an <invoke>, it is not required to have a <fromPart>
for every part in the WSDL message definition, nor is the order in which parts
are specified relevant. Parts not explicitly represented by <fromPart>
elements are not copied from the anonymous WSDL variable to the variable.
[SA00052]
The outputVariable
attribute MUST NOT be used on an <invoke> activity that contains
a <fromParts>
element. TO: (bold
text between *** and *** has been inserted. The asterisks are in case the bold
is lost in email and are not part of the final text) The <fromPart> element is
similar to the <toPart>
element. The <fromPart>
element is used to retrieve data from an incoming multi-part WSDL message and
place it into individual WS-BPEL variables. When a WSDL
message is received on an <invoke> activity that uses <fromPart>
elements, the message is placed in an anonymous temporary WSDL variable of the
type specified by the relevant WSDL operation's output message. The <fromPart>
elements, as a group, act as a single virtual <assign>,
with each
<fromPart> acting as a <copy>.
Each <copy>
operation copies the data at the part of the anonymous temporary WSDL variable
referenced in the part attribute of the <fromPart>
into the variable indicated in the toVariable attribute. ***If the <copy> operation is copying an element part to an element
variable then the keepSrcElementName option for the operation is set to
"yes".*** The virtual <assign> MUST follow the same
semantics and generate the same faults as a real <assign> (see
section 8.4. Assignment). When a <fromPart>
is present in an <invoke>, it is not required to have a <fromPart>
for every part in the WSDL message definition, nor is the order in which parts
are specified relevant. Parts not explicitly represented by <fromPart>
elements are not copied from the anonymous WSDL variable to the variable.
[SA00052]
The outputVariable
attribute MUST NOT be used on an <invoke> activity that
contains a <fromParts>
element. 4) Middle of Section 10.4 FROM: [SA00058]
In a <receive> or <reply> activity, the variable referenced by the variable attribute MUST be a messageType variable whose QName matches the QName
of the input (for <receive>) or
output (for <reply>) message type used in
the operation, except as follows: if the WSDL operation uses a message
containing exactly one part which itself is defined using an element, then a
WS-BPEL variable of the same element type as used to define the part MAY be
referenced by the variable attribute of
the <receive> or <reply> activity. The result of
using a WS-BPEL variable in the previously defined circumstance MUST be
equivalent to declaring an anonymous temporary WSDL message variable based on
the associated WSDL message type. In the case of a <receive> activity, the incoming part’s value will be used to set the
value of the variable referenced by the variable attribute. In the case of a <reply>
activity the value of the variable referenced by the variable attribute will be used to set the value of the part in the anonymous
temporary WSDL message variable that is sent out. In the case of a <reply> sending a fault, the same logic applies. TO: (bold
text between *** and *** has been inserted. The asterisks are in case the bold
is lost in email and are not part of the final text) [SA00058]
In a <receive> or <reply> activity, the variable
referenced by the variable attribute
MUST be a messageType variable whose QName matches the QName of the input (for <receive>) or output (for <reply>)
message type used in the operation, except as follows: if the WSDL operation
uses a message containing exactly one part which itself is defined using an
element, then a WS-BPEL variable of the same element type as used to define the
part MAY be referenced by the variable attribute of
the <receive> or <reply> activity. The result of
using a WS-BPEL variable in the previously defined circumstance MUST be
equivalent to declaring an anonymous temporary WSDL message variable based on
the associated WSDL message type. *** The
copying of the element data between the anonymous temporary WSDL message
variable and the element variable acts as a single virtual <assign> with
one <copy> operation whose keepSrcElementName attribute is set to
"yes". The virtual <assign> MUST follow the same semantics and
use the same faults as a real <assign>.*** In the case
of a <receive> activity, the incoming part’s value will be used to set the
value of the variable referenced by the variable attribute. In the case of a <reply>
activity the value of the variable referenced by the variable attribute will be used to set the value of the part in the anonymous
temporary WSDL message variable that is sent out. In the case of a <reply> sending a fault, the same logic applies. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]