RE: LC54 Proposal

> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek.kopecky@deri.org]
> Sent: Wednesday, April 20, 2005 2:44 AM
> To: David Orchard
> Cc: WS-Description WG
> Subject: 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.
> 

Fair enough.  I'm more focused on the service compatibility part than
endpoint compat.

> 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.
> 

The attribute might be generated in an automated manner by some higher
level language.  But then WSDL might be generated from some separate
language too, and we don't disallow creation of wsdl.  

The ways that a service might be compatible or incompatible, which could
be specified in a semantic language or bpel or something else.  But it's
hardly likely that every service described by WSDL will also have that
extra specification.  This functionality allows for just WSDL aware
software to have a chance at knowing whether services are compatible or
not, and whether they will break or not.

> 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?
> 

I think the group ended up saying that an interface extension is a
compatible extension.  

> 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 22:32:00 UTC