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 Thursday, 30 October 2003 13:49:24 UTC