OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue R1 Proposal to Vote


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:dannyv@tibco.com]
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.

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]