W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2005

LC54 Proposal

From: David Orchard <dorchard@bea.com>
Date: Tue, 19 Apr 2005 17:30:21 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0F0B98B8@ussjex01.amer.bea.com>
To: <www-ws-desc@w3.org>
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


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.




Received on Wednesday, 20 April 2005 00:30:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:49 UTC