RE: [wsbpel] Issue R48 - Amended Proposal Resolved (both parts)

["Charlton Barreto" <barreto@adobe.com>]

Hi Diane,

I've uploaded the spec with my edits to CVS - updating the TOC, editing
in the R48 resolution, updating the footer representation of the
document name, and updating the editor's list. 

Attached is a log of the validation and well-formedness of the WS-BPEL
XSDs.

Cheers,

-Charlton.

-----Original Message-----
From: Monica.Martin@Sun.COM [mailto:Monica.Martin@Sun.COM] 
Sent: 24 January 2007 10:41
To: Diane Jordan
Cc: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue R48 - Amended Proposal Resolved (both parts)

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.



Validated and checked for well-formedness with Altova XMLSpy 2007Sp1 on 2007jan24:

File ...\ws-bpel\specifications\SchemaFiles\wsbpel_main.xsd is well-formed.
File ...\ws-bpel\specifications\SchemaFiles\wsbpel_main.xsd is valid.

File ...\ws-bpel\specifications\SchemaFiles\wsbpel_msgprop.xsd is well-formed.
File ...\ws-bpel\specifications\SchemaFiles\wsbpel_msgprop.xsd is valid.

File ...\ws-bpel\specifications\SchemaFiles\wsbpel_plinkType.xsd is well-formed.
File ...\ws-bpel\specifications\SchemaFiles\wsbpel_plinkType.xsd is valid.

File ...\ws-bpel\specifications\SchemaFiles\wsbpel_serviceref.xsd is well-formed.
File ...\ws-bpel\specifications\SchemaFiles\wsbpel_serviceref.xsd is valid.