Re: [whenToUseGet] PUT/POST & GET with SOAP

+1.

I'm all for doing away with the RPC convention. It's terrible that the
designer has to make the RPC vs Document design decision at the abstract
interface level -- forced by the fact that you have to define the part as a
type with RPC and an element with Document. And I really don't see what
value it adds other then letting you define your parts as types versus
elements.

Anne

----- Original Message -----
From: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
To: "David Orchard" <dorchard@bea.com>; <noah_mendelsohn@us.ibm.com>
Cc: "'Ian B. Jacobs'" <ij@w3.org>; <www-tag@w3.org>; <xml-dist-app@w3.org>
Sent: Tuesday, June 24, 2003 10:02 PM
Subject: Re: [whenToUseGet] PUT/POST & GET with SOAP


>
> Hi Noah,
>
> > * So-called RPC-Literal, which seems to be emerging from the WSDL work
> > group.  My understanding is that they are taking advantage of the
> > lattitude in SOAP to use [1] without [2].  The REST guidelines apply
> > equally to such RPC-literal as to RPC encoded, IMO.  Indeed, there is
some
> > reason to believe that RPC literal is emerging as the dominant usage
> > pattern for SOAP RPC, but we'll see.
>
> There is a move to eliminate the document/rpc split in WSDL ..
> which would result in quite a simplification IMO. The WG has not
> yet accepted this, but I believe it is possible.
>
> RPC would then simply become an application of the request/response
> pattern. In all likelihood there will be some hints which indicate
> that the messages being sent are defined using RPC conventions in
> mind, but probably nothing more than that.
>
> This is all highly speculative and my personal opinion at this time.
>
> Sanjiva.
>