[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - R48 - <toPart>s and Anonymous WSDL Variables Clarification
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.
Section 10.3.1, Change from:
The <toPart> elements, as a group, act as the single virtual <assign>, with each <toPart> acting as a <copy>....[existing static analysis requirement 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.
Change to:
...The <toPart> elements, as a group, act as the single virtual <assign>, with each <toPart> acting as a <copy>. [add sentence] [add Static Analysis Requirement] At most one <toPart> exists for each part in the WSDL message definition. If a process includes more than one <toPart> for each part in the WSDL message definition, that process MUST be rejected by static analysis.[end sentence]...[updated static analysis requirement SA00050] When <toParts> is present, it is required to have a <toPart> for every part in the WSDL message definition; the order in which parts are specified is irrelevant. 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.
Appendix B
Notes:
See topart-issue-pr2.zip (document details) for a redlined copy of changes proposed for Section 10.3.1.
Links: Monica J. Martin, 22 Jan 2007
monica.martin@sun.com, 22 Jan 2007
Monica J. Martin, 22 Jan 2007
Alex Yiu, 23 Jan 2007
Changes: 23 Jan 2007 - 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 - R48 - [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 - R48 - Proposed resolution", without any Re: or similar.
To add a new issue, see the issues procedures document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]