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

RE: LC54 Proposal

From: Jacek Kopecky <jacek.kopecky@deri.org>
Date: Fri, 22 Apr 2005 00:31:11 +0200
To: David Orchard <dorchard@bea.com>
Cc: WS-Description WG <www-ws-desc@w3.org>
Message-Id: <1114122671.3330.39.camel@Kalb>

Dave, 

I don't think I was overstating much how close your service
compatibility gets to target resource, and here's my reasoning:

What I call service compatibility means that, in some common sense, the
two services 1) do the same thing 2) in the same place.

"Doing the same thing" is already there in the interfaces (if interface
extensions are compatible) - basically the services have to share an
interface so that the information that they do the same thing is useful
to a computer. If they don't share an interface but still are
compatible, they have duplicity in their interface definitions.

Now doing the same thing "in the same place" introduces the
considerations of what that place is, which is the same as what target
resource tried to be.

Tell me, please, what exactly do you envision that a WSDL processor (of
any kind) will do with service equivalence information? Let's try to see
if we agree on the intent, then we might get back to implementation of
that intent.

Best regards,

Jacek


On Thu, 2005-04-21 at 11:46 -0700, David Orchard wrote:
> I *hope* I'm not re-opening the target resource debate as I think this
> is quite simpler, but it is service compatibility that I want from my
> proposal.  I don't think this is at all the same as target resource
> because target resource attempted to make some specification about the
> resource behind the service, and thence one could infer some
> compatibility guarantees from service/targetresource pairs.  
> 
> My proposal avoids that problem by making the assertion much simpler,
> which is that a particular service can be used by a client as if it was
> another service.  
> 
> The relationship is between services, rather than services &
> targetResource.  Further, target resource brought in a bunch more
> things.  
> 
> Dave
> 
> > -----Original Message-----
> > From: Jacek Kopecky [mailto:jacek.kopecky@deri.org]
> > Sent: Thursday, April 21, 2005 12:45 AM
> > To: David Orchard
> > Cc: WS-Description WG
> > Subject: RE: LC54 Proposal
> > 
> > > > 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.
> > 
> > David, isn't this enough for the purposes of LC54?
> > 
> > There may be two kinds of compatibility here, only one caught in LC54
> as
> > it stands now:
> > 
> > Interface compatibility, what I would call the compatibility of intent
> > or function, which apparently is guaranteed for operations of
> interfaces
> > that are being extended by other interfaces.
> > 
> > Service compatibility, similar to target resource (R.I.P.) which says:
> > "if you call this common operation on either of these services, it's
> > going to do the same thing in the same place". The same seems to be
> the
> > intent of endpoint compatibility.
> > 
> > If service compatibility is not what you want, interface compatibility
> > should suffice for your purposes, because if two services don't share
> an
> > interface, information about their compatibility will be useless to
> > automated tools anyway.
> > 
> > If, on the other hand, you do want service compatibility, it seems to
> me
> > you're reopening the target resource debate.
> > 
> > Please clarify, which is it you want? 8-)
> > 
> > Best regards,
> > 
> > Jacek
> 
> 
Received on Thursday, 21 April 2005 22:31:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:35 GMT