- From: christopher ferris <chris.ferris@east.sun.com>
- Date: Wed, 25 Jul 2001 11:09:07 -0400
- To: Jacek Kopecky <jacek@idoox.com>
- CC: John Ibbotson <john_ibbotson@uk.ibm.com>, xml-dist-app@w3.org
+1 to John's proposal I agree that RPC is not technically an extension, but I would support its separation from the core SOAP specification for the very reasons that John identifies. Cheers, Chris Jacek Kopecky wrote: > > John, > do you have any points for why you see RPC as an extension? As > it is now, it doesn't even specify its own block (like > <rpc:call>) in which the data would go. It puts the data in the > body, that's why I see it as an application (I use this term to > differentiate from the formal SOAP extensions). > I agree that RPC could be made into a proper extension, but then > I don't see why this should be done. > I'm starting to thing that encoding really does belong to RPC > more than to the core, but the divison into 1+2 and 3+4 would (at > least in some people's minds) tie the encoding with RPC and > nobody would use it apart. And it would tie our RPC with our > encoding as well. > I also agree that our RPC is the major user of our encoding, so > the tyings aren't necessarily that bad. > I hope you don't mind me cc'ing the list again. > Best regards, > > Jacek Kopecky > > Idoox > http://www.idoox.com/ > > On Wed, 25 Jul 2001, John Ibbotson wrote: > > > > > Jacek, > > Yes, that's what I mean by an extension. > > > > However I see encoding as being linked to RPC (unless I've missed > > something) so I do see the split as 1+2 and 3+4 and as 2 separate > > documents. > > > > John > > > > XML Technology and Messaging, > > IBM UK Ltd, Hursley Park, > > Winchester, SO21 2JN > > > > Tel: (work) +44 (0)1962 815188 (home) +44 (0)1722 781271 > > Fax: +44 (0)1962 816898 > > Notes Id: John Ibbotson/UK/IBM > > email: john_ibbotson@uk.ibm.com > > > > > > > > > > Jacek Kopecky > > <jacek@idoox.c To: John Ibbotson/UK/IBM@IBMGB > > om> cc: xml-dist-app@w3.org > > Subject: Re: RPCTF: Should RPC be core or an extension ? > > 07/25/2001 > > 02:14 PM > > Please respond > > to Jacek > > Kopecky > > > > > > > > > > > > > > > > John, > > do you mean an extension in terms of the SOAP extension > > mechanism (headers, mustUnderstand, faulting)? > > For example I believe encoding cannot be made into such an > > extension. And my opinion is that RPC is not an extension either, > > that it's an application (usage pattern with some rules) of SOAP. > > I agree that the spec could be split into a few parts: > > 1) SOAP core > > 2) transport protocol bindings > > 3) data encoding > > 4) rules for RPC > > But IMO RPC should be split apart from encoding. Also IMO > > bindings and encoding belong to the core document as optional > > normative(*) parts. Then the RPC document could be made into an > > optional normative part as well, with some text that clearly > > separates these parts from the core. > > There is already a precedent for splitting - the XML Schema rec. > > I tend to prefer one document for SOAP, but I'd probably have no > > problem with splitting SOAP into two documents - 1+2+3 and 4, I > > wouldn't like the split to be 1+2 and 3+4. It could also be 1+2 > > and 3 and 4, but that's too many documents then, if we also > > release the abstract model and a primer. 8-) > > Best regards, > > > > Jacek Kopecky > > > > Idoox > > http://www.idoox.com/ > > > > (*) by an optional normative part I mean that it specifies > > something that needn't be used, but if used, this part is > > normative. If there is a better term for this or if this is an > > oxymoron (which depends on what normative exactly means here), > > please let me know. 8-) > > > > > > > > > > > > On Wed, 25 Jul 2001, John Ibbotson wrote: > > > > > Should RPC be part of the core SOAP specification or an architected > > > extension ? > > > > > > I believe the SOAP 1.1 specification confused matters by including > > sections > > > on RPC and encoding. Readers of the specification came to the incorrect > > > conclusion that SOAP was inextricably linked to RPC. As Henrik pointed > > out > > > inthe early days of the WG, SOAP is really only a single way message > > with > > > RPC being a convention for linking two single way messages into a > > > request/response pair together with an encoding mechanism. By removing > > RPC > > > from the core specification and placing it into a separate extension, we > > > have the opportunity to correct the confusion that I believe originates > > > from SOAP 1.1. > > > > > > There is a second reason for removing RPC from the core specification. > > > There is a large body of users (the EDI community via ebXML) for whom > > RPC > > > is not the preferred invocation mechanism. They operate with a document > > > exchange model which may include boxcarring of business documents in a > > > single message each of which is of equal processing importance. If the > > WG > > > perpetuates the perceived importance of RPC by including it in the core > > > specification rather than viewing it as an extension, then acceptance of > > > SOAP in some communities may be diminished. > > > > > > Comments please, > > > John > > > > > > XML Technology and Messaging, > > > IBM UK Ltd, Hursley Park, > > > Winchester, SO21 2JN > > > > > > Tel: (work) +44 (0)1962 815188 (home) +44 (0)1722 781271 > > > Fax: +44 (0)1962 816898 > > > Notes Id: John Ibbotson/UK/IBM > > > email: john_ibbotson@uk.ibm.com > > > > > > > > > > > > > >
Received on Wednesday, 25 July 2001 11:09:14 UTC