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)



The revision history should be removed from all the docs when we get to the oasis standard.  Until then we can leave it in.  
I can't recall if there were changes to the schema from the public review 2 updates we made.  If so, we need to post them back to the TC web site.  Would you please do that?    
Regards, Diane
IBM  Emerging Internet Software Standards
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709



Thomas Schulze <ThomasSchulze@de.ibm.com>

01/26/2007 08:38 AM

To
"Charlton Barreto" <barreto@adobe.com>, Diane Jordan/Raleigh/IBM@IBMUS
cc
wsbpel@lists.oasis-open.org
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]