Re: LC54 Proposal

Dave, 

I don't like the endpoint part of this proposal. In my understanding,
all endpoints of a service are basically equivalent in function
(although non-functional parameters like binding and some features may
vary on endpoints), therefore if a service evolves in an incompatible
manner, all of its endpoints will have likewise evolved.

I'm somewhat doubtful about the service compatibility part, too, it
seems like it's out of scope of WSDL, belonging instead to the semantic
description layer envisioned above. In particular, saying that a service
has the same (or compatibly extended) functionality as another service
seems to belong to the same language as saying what the service actually
does - that's what the various SemWebService languages (WSMO, OWL-S) try
to do.

So far we've punted on saying anything about the functionality
(semantics) of services (or interfaces, for that matter) and it seems
that your proposal goes in that direction, opening discussions similar
to that about target resource.

BTW, what happened to the original intention (caught in the issue) of
indicating compatibility on interfaces as opposed to services? If you
want to go in this direction, wouldn't starting at interface be cleaner?

Best regards,

Jacek

On Tue, 2005-04-19 at 17:30 -0700, David Orchard wrote:
> 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 09:43:40 UTC