Update of schema 2.x ; also issues to discuss concerning WS modules

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Hi,

Keith, I hope you will be finishing up your interop work and get a
chance to look this over.

I am attaching an updated 2.x schema (still working draft of course)
that provides for substitution groups that will allow us to add support
for web services and eventually, business process sequencing notations
or languages other than BPSS. [There are detailed comments about the
schema changes in a document in the zip file. While it now validates in
XSV and XMLSpy (in text view mode only,however), there is still a number
of things to be fixed and/or completed.]

A placeholder proposal for a WSDL (1.1) DocExchange module is also found
in the schema so that you can see how it would work. This proposal adds
under the DocExchange element a new WSDLBinding element that is a member
of the substitution group for DocExchangeBinding. The only module
currently declared in this element is wsdl:definitions, from the wsdl
1.1 namespace.
The wsdl:definitions element is, of course, the root element

Here are some advantages/disadvantages I see in this proposal. 

Advantages
1. Just drops in the WSDL as is, no changes needed (to the wsdl anyway).
So, CPP and CPA processors can then dispatch to existing WSDL processing
methods, if desired. Very simple approach.
2. A match between the proposed WSDL of Party A (always in a CanReceive)
by Party B could possibly be something indicated by putting an IDREF
back to defining WSDL of Party A. In a CPP, the willingless to accept
WSDLs could, by convention, be indicated by an empty WSDLBinding element
under B's CanSend. Maybe a more discriminating interest in WSDLs could
also be supported somehow. I would personally be very reluctant to put a
"Solicit-Response" counterpart to a "Request-Response" WSDL and try to
match things up in detail.
3. The Transport element could be ignored if a port or endpoint (v 2.0)
is found in the WSDL, or the tp:Transport element could be used to
settle on a URI at Negotiation time, allowing some customization of URIs
between TPs. 

Disadvantages
1. Possible conflict between Endpoint/Port value and Transport endpoint
value. So there probably should be a constraint on the Transport URI
value to match any wsdl port/endpoint value appropriately. If so, the
additional info on certificates and trust anchors under our Transport
element could augment the collaboration agreement and the wsdl.
2. No checking duplication/consistency of WSDL Features & Properties
with features and properties already defined in CPPs and CPAs. Need to
consider what problems could arise here.
3. How do we set syncReplyMode values appropriately? Similar questions
for other MessagingCharacteristics properties.
4. I realized that we don't have a clean way to indicate that the
Packaging is, for example, just a simple SOAP envelope.
I am going to add that issue to CPPA core group for discussion.




I also put some DocExchange binding placeholders for EDIINT and SOAP and
SwA (SOAPwithAttachments). I think that the capability modules defined
under the SOAP binding may also be ones that can occur under the
WSDLBinding extension.

As you can see, I am seeking to confine WS related changes to the
DocExchange element. 

The ProcessSpecification element also is now just one way to refer to BP
sequencing notations, and once we decide on handling WS, we can relate
the atoms of WS to the WS based sequencing notations.