- From: Jacek Kopecky <jacek@systinet.com>
- Date: Fri, 3 May 2002 16:35:43 +0200 (CEST)
- To: noah_mendelsohn@us.ibm.com
- cc: moreau@crf.canon.fr, <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>
Noah, thanks for this info. I think that in this case we must decide how we understand it in SOAP 1.2: a) first you understand the first QName in the Body, then you know it's RPC and the ProcedureNotPresent fault has no meaning then (and also it seems that RPC cannot forbid multiple invocations in one Body then), b) or RPC is application of SOAP governing the whole Body, in which case ProcedureNotPresent has sense. We are currently saying we don't mandate any kind of semantics in Body (except for the Fault), which would indicate that we'd better stick with (b) as then RPC gets to say what Body is (as opposed to some higher level of contract which uses RPC for particular QNames). Best regards, Jacek Kopecky Senior Architect, Systinet (formerly Idoox) http://www.systinet.com/ On Fri, 3 May 2002 noah_mendelsohn@us.ibm.com wrote: > History: FWIW, I was involved in consideration of this issue for the > design of 1.1. There, we explicitly decided that a receiver was expected > to understand the QName in the body, and from that would understand any > conventions associated with the use of that body. I agree with Henrik > that it's circular (and unnecessary) to model a misunderstood Body QName > differently for RPC than for any other use of the Body. Not recognizing > that it's a purchase order (presumed message style) is no different than > not recognizing getStockQuote (presumed RPC style), IMO. Only when you > recognize it do you understand whether there are good mappings to the RPC > method/args style (and as Henrik points out, the degree to which you > actually do a nice binding to a programming language is completely private > to your endpoint.) > > ------------------------------------------------------------------ > Noah Mendelsohn Voice: 1-617-693-4036 > IBM Corporation Fax: 1-617-693-8676 > One Rogers Street > Cambridge, MA 02142 > ------------------------------------------------------------------ > > >
Received on Friday, 3 May 2002 10:36:00 UTC