- From: David Orchard <dorchard@bea.com>
- Date: Tue, 19 Apr 2005 17:30:21 -0700
- To: <www-ws-desc@w3.org>
- Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0F0B98B8@ussjex01.amer.bea.com>
I'd like to propose a marker for indicating compatibility. This takes the form of an attribute called "isCompatibleWith". It can contain a list of Qnames. It indicates that the containing component is compatible with any of the identified components. Compatibility is described at the component level. Lack of the attribute does not indicate incompatibility. This attribute can occur on services and endpoints. It is copied into the component model from the infoset representation. A service compatibility guarantee is an indication of the intent that a client of the identified service(s) can interact with the contained service without modification. Some of the changes in a service that would be good candidates for compatible are: addition of optional operations, addition of optional yet supported bindings, addition of optional endpoints. An endpoint compatibility guarantee is that a client of the identified endpoint can interact with the contained endpoint without modification. A service might evolve in an incompatible manner but some of the endpoints within the service remain compatible. A binding compatibility guarantee is not needed because bindings are realized in services and endpoints. A binding could evolve in a compatible way, such as when the referenced interface evolves in a compatible way. However, the service compatibility guarantee encompasses binding compatibility guarantees. It is always the case that WSDL components may be modified yet retain the original QName. It is strongly advised that modifications to components that are incompatible should result in new QNames. It is possible that modifications to components that are compatible changes do result in new Qnames, and the isCompatibleWith provides the compatibility guarantee in this scenario. Cheers, Dave
Received on Wednesday, 20 April 2005 00:30:23 UTC