In that case, how about changing:
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.
The virtual <assign> MUST follow the same sematics
and use the
same faults as a real <assign> with the one exception being
that the <copy> operation's keepSrcElementName
attribute is
set to "yes" by default.
To
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> with
the one exception being that the <copy>
operation's keepSrcElementName attribute is
set to "yes" by default.
Danny
Mark Ford wrote:
There is no
other option so I’ll
drop the phrase from the proposal. Good catch.
From: Danny van der
Rijn [mailto:]
Sent: Wednesday,
October 25, 2006
12:29 PM
To: Mark Ford
Cc: 'wsbpeltc'
Subject: Re: [wsbpel]
Issue R1
Proposal to Vote
I don't understand the use of the phrase "by
default" in the
two additions where it appears. Is there another option?
Mark Ford wrote:
This proposal is based on
the outline I sent back on October
6. It solves the issue with keepSrcElementName behavior for the virtual
assigns
by adding text to the spec to make the keepSrcElementName behavior
implicitly
enabled for virtual assigns.
The following changes are
proposed:
1) Last paragraph in
Section 10.3
FROM:
[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)
[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. ***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.
The virtual <assign> MUST follow the same sematics
and use the
same faults as a real <assign> with the one exception being
that the <copy> operation's keepSrcElementName
attribute is
set to "yes" by default.*** 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.
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.
The virtual <assign> MUST follow the same sematics
and use the
same faults as a real <assign> with the one exception being
that the <copy> operation's keepSrcElementName
attribute is
set to "yes" by default.*** 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.
