[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue R48 - Amended Proposal Resolved (both parts)
Diane, in the public review 2 we've made no chnages to the schemas. Best regards/Mit freundlichen Grüßen, Thomas Schulze Diane Jordan <drj@us.ibm.com> To 30.01.2007 17:07 Thomas Schulze/Germany/IBM@IBMDE cc "Charlton Barreto" <barreto@adobe.com>, wsbpel@lists.oasis-open.org 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> To 01/26/2007 08:38 AM "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) (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]