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 R48 - Amended Proposal Resolved (both parts)



Hi Charlton,

The log of the validation and well-formedness of the schemas includes only
four schemas instead of five and does show the old schema names. The five
final BPEL 2.0 schemas can be found in the sourceforge folder
\specifications\SchemaFiles\ws-bpel_2.0_schema_2006_08
(http://wsbpeltc.cvs.sourceforge.net/wsbpeltc/specifications/SchemaFiles/ws-bpel_2.0_schema_2006_08/):
- ws-bpel_abstract_common_base.xsd
- ws-bpel_executable.xsd
- ws-bpel_plnktype.xsd
- ws-bpel_serviceref.xsd
- ws-bpel_varprop.xsd

Diane,
these schemas still contain the change histories. Will we remove them
before entering the OASIS standardization process? Will we remove the
revision history in the spec?

Best regards/Mit freundlichen Grüßen,

       Thomas Schulze



                                                                       
             "Charlton                                                 
             Barreto"                                                  
             <barreto@adobe.co                                          To
             m>                        "Diane Jordan" <drj@us.ibm.com> 
                                                                        cc
             25.01.2007 23:00          <wsbpel@lists.oasis-open.org>   
                                                                   Subject
                                       RE: [wsbpel] Issue R48 - Amended
                                       Proposal Resolved (both parts)  
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       




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.



(See attached file: validation.2007jan24.txt)
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.


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