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

 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 10:01:24 UTC