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: Issue - 257 - Wrapper Element for fromPart & toPart

This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if a motion to open the issue is proposed and that motion is approved by the TC. A motion could also be proposed to close it without further consideration. Otherwise it will remain as "received".

The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - 257 - Wrapper Element for fromPart & toPart

Status: received
Date added: 3 Apr 2006
Categories: Syntax and validation
Date submitted: 03 April 2006
Submitter: Dieter Koenig
Document: WS-BPEL 2.0 Specfication (03 Apr 2006)
Description: WS-BPEL defines wrappers for element sequences like <variables>, <partnerlinks>, <correlations>, <sources>, <targets>, and many others. The only place where a list of elements is not contained in a wrapper element is <fromPart> and <toPart>. For consistency, corresponding wrappers <fromParts> and <toParts> should be introduced as well.

Submitter's proposal: In all message activities, introduce wrappers <fromParts> and <toParts> for the <fromPart> and <toPart> elements, respectively.

Section 5.2 (<process> syntax): change 

   <fromPart part="NCName" toVariable="NCName"/>*
to 
   <fromParts>?
      <fromPart part="NCName" toVariable="NCName"/>+
   </fromParts>

Section 5.2 (<receive> syntax): change 

   <fromPart part="NCName" toVariable="NCName"/>*
to 
   <fromParts>?
      <fromPart part="NCName" toVariable="NCName"/>+
   </fromParts>

Section 5.2 (<reply> syntax): change 

   <toPart part="NCName" fromVariable="NCName"/>*
to 
   <toParts>?
      <toPart part="NCName" fromVariable="NCName"/>+
   </toParts>

Section 5.2 (<invoke> syntax): change 

   <toPart part="NCName" fromVariable="NCName"/>*
   <fromPart part="NCName" toVariable="NCName"/>*
to 
   <toParts>?
      <toPart part="NCName" fromVariable="NCName"/>+
   </toParts>
   <fromParts>?
      <fromPart part="NCName" toVariable="NCName"/>+
   </fromParts>

Section 5.2 (<pick> syntax): change 

   <fromPart part="NCName" toVariable="NCName"/>*
to 
   <fromParts>?
      <fromPart part="NCName" toVariable="NCName"/>+
   </fromParts>

Section 10.3 (<invoke> syntax): change 

   <toPart part="NCName" fromVariable="NCName"/>*
   <fromPart part="NCName" toVariable="NCName"/>*
to 
   <toParts>?
      <toPart part="NCName" fromVariable="NCName"/>+
   </toParts>
   <fromParts>?
      <fromPart part="NCName" toVariable="NCName"/>+
   </fromParts>

Section 10.3 (explanation text): change

(...) The outputVariable attribute MUST NOT be used on an <invoke> activity that also contains a <fromPart> element. The choice to use the inputVariable form instead of the <toPart> form, or vice versa, creates no restriction on which outputVariable or <fromPart> form is used. Similarly, the choice to use the outputVariable form instead of the <fromPart> form, or vice versa, creates no restriction on which inputVariable or <toPart> form is used.
to:
(...) The outputVariable attribute MUST NOT be used on an <invoke> activity that also contains a <fromParts> element. The choice to use the inputVariable form instead of the <toParts> form, or vice versa, creates no restriction on which outputVariable or <fromParts> form is used. Similarly, the choice to use the outputVariable form instead of the <fromParts> form, or vice versa, creates no restriction on which inputVariable or <toParts> form is used.

Section 10.4 (explanation text): change

(...) An alternative to the variable attribute is the use of <fromPart> elements. The syntax and semantics of the <fromPart> elements as used on the <receive> activity are the same as specified for the <invoke> activity in section 10.3.1. Mapping WSDL Message Parts. This includes the restriction that if <fromPart> elements are used on a <receive> activity then the variable attribute MUST NOT be used on the same activity. Again, note that if a WSDL message definition does not contain any parts, then the associated variable attribute or <fromPart> elements MAY be omitted.
to:
(...) An alternative to the variable attribute is the use of <fromParts> element. The syntax and semantics of the <fromParts> element as used on the <receive> activity are the same as specified for the <invoke> activity in section 10.3.1. Mapping WSDL Message Parts. This includes the restriction that if <fromParts> element are used on a <receive> activity then the variable attribute MUST NOT be used on the same activity. Again, note that if a WSDL message definition does not contain any parts, then the associated variable attribute or <fromParts> element MAY be omitted.

Section 10.4 (<receive> syntax): change 

   <fromPart part="NCName" toVariable="NCName"/>*
to 
   <fromParts>?
      <fromPart part="NCName" toVariable="NCName"/>+
   </fromParts>

Section 10.4 (explanation text): change

(...) The <fromPart> element in a <receive> activity is used as an alternative to indicate that the data from a received message is to be directly copied to WS-BPEL variables from a corresponding anonymous WSDL message variable. Similarly, the <toPart> element is used as an alternative to have data from WS-BPEL variables directly copied into an anonymous WSDL message used by the <reply> activity.
to:
(...) The <fromParts> element in a <receive> activity is used as an alternative to indicate that the data from a received message is to be directly copied to WS-BPEL variables from a corresponding anonymous WSDL message variable. Similarly, the <toParts> element is used as an alternative to have data from WS-BPEL variables directly copied into an anonymous WSDL message used by the <reply> activity.

Section 10.4 (<reply> syntax): change 

   <toPart part="NCName" fromVariable="NCName"/>*
to 
   <toParts>?
      <toPart part="NCName" fromVariable="NCName"/>+
   </toParts>

Section 11.5 (explanation text): change

(...) The semantics of the onMessage event are identical to a receive activity regarding the optional nature of the variable attribute, the handling of race conditions, the single element-based part message short cut, the constraint regarding simultaneous enablement of conflicting receive actions and the optional use of <fromPart> elements.
to:
(...) The semantics of the onMessage event are identical to a receive activity regarding the optional nature of the variable attribute, the handling of race conditions, the single element-based part message short cut, the constraint regarding simultaneous enablement of conflicting receive actions and the optional use of <fromParts> element.

Section 11.5 (<pick> syntax): change 

   <fromPart part="NCName" toVariable="NCName"/>*
to 
   <fromParts>?
      <fromPart part="NCName" toVariable="NCName"/>+
   </fromParts>

Section 12.5.1 (<eventHandler> syntax): change 

   <fromPart part="NCName" toVariable="NCName"/>*
to 
   <fromParts>?
      <fromPart part="NCName" toVariable="NCName"/>+
   </fromParts>

Section 12.5.1 (explanation text): change

(...) An alternative to the variable attribute are <fromPart> elements. The syntax and semantics of the <fromPart> elements as used on the onEvent element are the same as specified in section 10.3 for the receive activity. This includes the restriction that if <fromPart> elements are used on an onEvent element then the variable, element and messageType attribute MUST NOT be used on the same element. When using the <fromPart> elements, each <fromPart> element constitutes an implicit declaration of a variable of that name within the associated scope of the eventHandler.
to:
(...) An alternative to the variable attribute is the <fromParts> element. The syntax and semantics of the <fromParts> element as used on the onEvent element are the same as specified in section 10.3 for the receive activity. This includes the restriction that if a <fromParts> element is used on an onEvent element then the variable, element and messageType attribute MUST NOT be used on the same element. Using the <fromParts> element constitutes an implicit declaration of a variable of that name within the associated scope of the eventHandler.

Changes: 3 Apr 2006 - new issue

To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 257 - [anything]" or is a reply to such a message. If you want to formally propose a resolution to an open issue, please start the subject line "Issue - 257 - Proposed resolution", without any Re: or similar.

To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).

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