ActionItem: WSDL and CPPA 2.X extension status

At the end of changes for version 2.0 of the CPPA core specification, a number of issues pertaining to extensibility were deferred.

Going forward, in addition to fixing known smaller issues and editorial snafus in the specifications, we want to see whether we can decide how the CPP and CPAs can be extended to cover new collaboration features, both in the BP area as well as in Messaging/Security.

One method for adding extensibility is by making use of substitution groups. To do this, we need to agree upon a process for considering changes.

Here is a draft of a possible process:

First, identify candidate elements for extensibility.

Second, decide whether the current element (supposing it has a complexType, and many/most do) should be given a standard conversion (retaining the complexType of the current element as the complexType of the "head" of the substitution group) or whether the current complexType for the element should become an extension of the complexType of the substitution group "head". [ Logically we could also ask whether the current complexType for the element should become a restriction of the complexType of the substitution group "head" -- I am uncertain whether there are use cases for this alternative, however.]

Third, decide on any new complex types that we will then extend into our version 2.0 types and insert �head� elements for the substitution group..

An example may help illustrate what can be done for a standard conversion. Here is what we currently have for the element { ProcessSpecification}.

</sequence>

</complexType>

</element>

A standard conversion would refactor this to obtain something like:

</sequence>

</complexType>

New elements could then be declared that could extend (or restrict) the ProcessSpecification.type.

If we are planning to allow alternative elements that do not preserve much of current structure, it's better to create a new minimal complex type, and do the current complex type as a substitution group that extends the type of the head element of the substitution group.

Here is a table I have started to track high level requirements. If we proceed along this path, TC members should provide their views on where we should introduce the substitution groups, and what tactic we should take. If you consider sticking in pointers to wsdl:porttype definitios, where should they go? Should we just have pointers or allow in-lining wsdl:porttypes, messages, parts, types, etc. For wsdl:bindings that are SOAP bindings, should they go under DocExchange? How would you like to see the refactoring work? Also, consider using choreography languages with more complexity than the basic wsdl MEPs Should other messaging approaches be captured? EDIINT, RNIF, and so on... We need both candidates for substitution group extensibility and use case motivation for the approach we adopt. I hope this chart can maybe get you thinking about what should be done and where, and then follow up on this approach in San Diego. Also if anyone finds a good tutorial on substitution groups that they would recommend to the TC, please post one. [ I have found examples using the search engines, but not much discussing design alternatives and tradeoffs.]

	Candidate	Head element added	Version 2.0 is Restriction/Extension	New complexType needed
ProcessSpecification	Y	Y
Service	Y	Y
Protocol	Y

CollaborationRole	Y	Y		Yes
ActionContext	Y	Y		Yes
Transport	Y	Y
DocExchange	Y	Y		Yes
ServiceBinding	Y	Y	Yes	Yes
Packaging	Y	Y
SimplePart	Y	Y
CanSend	?
CanReceive	?
MessagingCharacteristics	Y	Y
BusinessCharacteristics	Y	Y
SecurityDetails	Y	Y
DeliveryChannel	Y	Y
CPP	N	N
CPA	N	N

ebxml-bp message

ebxml-cppa message