Re: RPCTF: Should RPC be core or an extension ? -- A PROPOSAL

John:

         I was tripped up on the point of RPC's being in CORE on the last 
RPC Task Force call.  In reading Section 7, I got the impression that RPCs 
are a major goal of SOAP.:

"One of the design goals of SOAP in to encapsulate remote procedure call 
functionality..."

I was quickly corrected and was pointed to the INTRODUCTION.

"The SOAP RPC representation (see section 7) defines a convention that can 
be used to represent remote procedure calls and responses."  The KEYWORD 
seems to be "can" in lowercase.

I would like to propose:

1.) We make optional and mandatory keywords  CAPS.  OPTIONAL is defined as 
a Keyword in CAPS, but is used in lowercase in the SOAP Version 1.2 9 July 
2001 document.   MANDATORY is not a Keyword and like optional is used in 
lowercase with two   "Mandatory"

2.) Assign FeatureIDs to each feature and then create a table of CORE SOAP 
features and assign OPTIONAL or MANDATORY to each feature.  This will aid 
in the development of conformance claims requirements for SOAP 1.2 
implementations.

3) Create the concept of PACKAGES that extend SOAP 1.2, and this may be 
where the RPC parts belong.  Again, assign FeatureIDs to the features in a 
package and define what is MANDATORY or OPTIONAL.  These can be listed in 
separate tables and again would help in conformance claims requirements for 
SOAP extension package implementations.

This would make it clear what is in CORE SOAP 1.2 and what is needed to 
have a conformant implementation and give a structure for developing 
extensions to the CORE SOAP in the future.

chuck

At 11:33 AM 7/25/2001 +0100, 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

========================================================
Charles E. Campbell Ph.D.                916-988-7144 Voice
Senior Standards and Language Architect  916-988-6092 Fax
IBM
P.O. Box 622198                          916-300-1205 Mobile
Orangevale, CA 95662                     916-988-3501 HOME

EMAIL:
Business:  campbelc@informix.com
Personal:  campbelc@calweb.com
            campbelc@ix.netcom.com
            campbelc@isontheweb.com
            campbelc46@hotmail.com
            campbelc@acm.org

========================================================
The opinions that I express are my own and may or may-not be
those of my employer IBM
========================================================