RE: New issue [distobj@acm.org: Re: What does WSDL describe?]

I'd like to resurrect this thread so we can discuss the issue this week.

Mark, I am still quite murky on precisely what change you're asking for
in the language, which kind of processors would benefit from the change,
and how.  Are you asking for a marker on each operation, indicating
whether the operation "transfers" or "transports" state?  What concrete
benefit could a processor provide when given such information?
 
> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of Mark Baker
> Sent: Thursday, October 30, 2003 10:45 AM
> To: Jacek Kopecky
> Cc: WS-Description WG
> Subject: Re: New issue [distobj@acm.org: Re: What does WSDL describe?]
> 
> 
> Hi Jacek,
> 
> On Thu, Oct 30, 2003 at 04:59:38PM +0100, Jacek Kopecky wrote:
> > Please see below.
> >
> > > "What can a symbol
> > > require of a person? Nothing. What can receipt of a message which
uses
> > > a symbol require of a person? Nothing. You can't require people to
do
> > > thing by sending them things.
> > >
> > > We can define a *protocol* in which people do do things, and we
can
> > > demonstrate
> > > that if people adhere to the protocol interesting results can be
> > > assured.  Then conformance with the protocol would require that
one do
> > > something."
> > >  -- http://lists.w3.org/Archives/Public/public-sw-
> meaning/2003Sep/0130.html
> >
> > This is very insightful, and IMO a WSDL operation is a protocol.
> 
> Agreed.
> 
> > In case the above isn't sufficient, please read on. 8-)
> >
> > Sending documents isn't sufficient, my software never just sends a
> > document to some service. My software always sends some documents to
> > some endpoints *expecting that an agreed thing will be done*.
> 
> Depends what you mean by "send" and "document" 8-).
> 
> *Transporting* state (like Savas' example) isn't sufficient, but
> transferring it is, because transfer includes the expectation that you
> speak of.
> 
> > I don't
> > just come up to a clerk and hand it an new-bank-account form.  I
usually
> > go to *a bank* (a service endpoint with a known interface), give
them a
> > *new-bank-account form* (the agreed document structure) and expect
that
> > *an account is going to be opened for me* (the semantics).
> 
> Ok, though I could see that being a result of submitting it to a clerk
> too.
> 
> (and FWIW, the SOAP Action feature is for declaring that expectation
in
> the request message)
> 
> > Now the semantic agreement can be per service, i.e. a service can
tell
> > me what submitting a document to it with the structure given by the
> > operation will result in; or it can be per interface, i.e. the
creator
> > of the interface can tell me what submitting a document with the
> > structure given by the operation will do, and the service just tells
me
> > how to submit the document and where to submit it.
> 
> Per-service is more self-descriptive since the description is in the
> message rather than in some separate document.  But sure, both could
be
> used.
> 
> > In other words, "per service" means one can define an interface that
> > will involve new-bank-account forms, a company can advertise that
they
> > implement it and then I'll call them up and ask them, what they do
with
> > new-bank-account forms. "Per interface" means one can define a bank
> > interface involving new-bank-account, my parent teaches me (in lieu
of
> > me having to call the creator of the bank interface) that a bank is
> > where I put money into accounts, and when I see a company
advertising
> > they do banking, I don't have to call them and ask them if that
involves
> > putting money in accounts.
> 
> Right.
> 
> > An operation always means *do something* and it need not be RPC. If
I
> > don't know what a service does, I can only ignore it.
> 
> Hmm, I'm not sure what you mean by that last sentence, but it doesn't
> sound good 8-).  I think we were mostly in agreement up to that point.
> But I'm also not sure how what you're talking about above relates to
my
> issue.  Can you elaborate please, perhaps with a simple "Yes I agree",
> or "No, I don't", since my brain is hurting after all this. 8-)
> 
> Thanks.
> 
> Mark.
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>

Received on Tuesday, 11 November 2003 12:38:52 UTC