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)
- From: Diane Jordan <drj@us.ibm.com>
- To: Thomas Schulze <ThomasSchulze@de.ibm.com>
- Date: Tue, 30 Jan 2007 09:07:33 -0700
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]