Issue R48 - Amended Proposal Resolved (both parts)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Resolution to R48 - as agreed on TC call Jan 24 in two parts (combined 
herein):

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>.  At most one
    <toPart> exists for each part in the WSDL message
    definition....[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

    * Update SA00050 in Appendix B as proposed (as it uses this text
      'When <toParts> is...rejected by static analysis.').

Futures (part of discussion but not the proposal)

    * Consider how to more effectively reference static analysis
      requirements so renumbering / rearranging work is minimized and
      references are consistent across those changes. This may be
      addressed later in a Maintenance mode.