Re: RPCTF: Should RPC be core or an extension ?

 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 09:14:52 UTC