Subsitution groups for DocExchange to allow WS module support.

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

Hi,

I am attaching a very preliminary schema showing one way we might modify
the DocExchange & subordinate elements to allow for describing
capabilities and agreements on the use of SOAP modules and features or
other web services related information in other notations.

The schema starts out from just a stripped down PartyInfo element to
give the example some context, and then shows new complexTypes,
substitution group heads, and various of the options/choices for
variation at the substitution group head "sites". 

A number of comments asking questions we should consider are included in
the schema. 

I have proposed that we might put specific information about SOAP1.1 and
SOAP1.2 but have not considered how and what to capture. Candidates
include Features and Properties, header block and module identifying
URIs, etc.  I also indicated where WS Policy Language bits might be
aggregated, where wsdl:binding elements might be placed, and so on. 

Before diving into the details, consider whether the DocExchange element
is a satisfactory location for these kinds of data. 
Also there are occasional gotchas. For example, the wsdl:binding element
uses a "Qname" reference device to hook up to the portType/interface
that it is a binding for. Should we include the interface (and its
messages, parts, and types that it drags along) somewhere or just
provide a link to a document. If we do that, maybe we should simply
reference the wsdl:binding element, so that a wsdl processor could be
separately invoked? 

There should be a lot of room for comment and questions at this point.
As this extension framework stabilizes, then I think we can begin to
dive into the details of what and how to include or reference of all the
more detailed information that will be needed in supporting agreements
on web-services-based collaboration.

Also since substitution groups are still on the exotic construct list,
here is a reference to a summary of techniques
http://www.xfront.com/VariableContentContainers.html that I think is
interesting [even though I did not buy into all the evaluative
assumptions expressed.] I found another helpful explication of
complexTypes and their flavors at
http://www.xml.com/lpt/a/2001/08/22/easyschema.html, which comes in
handy when doing this kind of refactoring.

Also I have not yet checked the test schema fragment against any
examples. I hope to get time to pare down some examples from CPPA v 2.0
instances to check against the schema to check the conservative
extension constraints that we are aiming for. I am sure there is work to
do to get it the way we want it. 

Also I have not tried to "subset" or constrain the substitution options
so that restrictions on mixing and matching various alternatives in
different groups are prohibited. If you understand that issue, and know
what constraints we want to enforce, please let me know any requirements
in that area.


Dale

PartyInfoDocExchange.xsd