- From: Anne Thomas Manes <anne@manes.net>
- Date: Tue, 24 Jun 2003 22:17:31 -0400
- To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, "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>
+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. >
Received on Tuesday, 24 June 2003 22:30:37 UTC