[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] Issues pertaining to CPPA extensibility.
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}.
<
element name="ProcessSpecification"><complexType>
<sequence>
<element ref="ds:Reference" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="name" type="tns:non-empty-string" use="required"/> <attribute ref="tns:version" use="required"/> <attributeGroup ref="tns:xlink.grp"/> <attribute name="uuid" type="anyURI"/> </complexType> </element>A standard conversion would refactor this to obtain something like:
<element name="ProcessSpecification.head" type="tns:ProcessSpecification.type" abstract="true"/> <element name="ProcessSpecification" substitutionGroup="tns:ProcessSpecification.head"/> <complexType name="ProcessSpecification.type"> <sequence> <element ref="ds:Reference" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="name" type="tns:non-empty-string" use="required"/> <attribute ref="tns:version" use="required"/> <attributeGroup ref="tns:xlink.grp"/> <attribute name="uuid" type="anyURI"/> </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 |
|
|
|
Service |
Y |
|
|
|
Protocol |
Y |
|
|
|
|
|
|
|
|
CollaborationRole |
Y |
|
|
Yes |
ActionContext |
Y |
|
|
|
Transport |
Y |
|
|
|
DocExchange |
Y |
|
|
|
ServiceBinding |
Y |
|
Yes |
|
Packaging |
Y |
|
|
|
SimplePart |
Y |
|
|
|
CanSend |
? |
|
|
|
CanReceive |
? |
|
|
|
MessagingCharacteristics |
Y |
|
|
|
BusinessCharacteristics |
Y |
|
|
|
SecurityDetails |
Y |
|
|
|
DeliveryChannel |
Y |
|
|
|
CPP |
N |
|
|
|
CPA |
N |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC