Re: RPC Mapping

>> These appear in the same order as in the procedure or method signature

What method signature?  Isn't this verging on something that belongs in 
the WSDL spec rather than SOAP?  In the SOAP rec, I think we can say 
things like:  A SOAP RPC represents its arguments as a struct;  the order 
of the arguments is considered significant (in/out arguments appear 
first..., or whatever)."

I think one could even go as far as:

NOTE:  for interoperability, when binding SOAP RPC to programming language 
API's, it is customary to map the arguments of such language API's in 
order to the respective arguments in the SOAP RPC call.  Similarly, 
description languages (such as WSDL) customarily document the arguments in 
the order that they appear in the message.

...or some such.   I'm not sure that note really belongs, but that's about 
as far as I'd go.   I don't see how we can make a normative reference to a 
"method signature", unless we want to spell out a model for one (I suppose 
we could go that route too).  Does this make sense?

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

"Martin Gudgin" <>
Sent by:
02/08/2002 10:35 AM

        To:     "XML Protocol Discussion" <>
        Subject:        RPC Mapping

In the editors copy of Part 2[1], section 4.1[2] states of [in] and 
parameters in the request that;

'These appear in the same order as in the procedure or method signature.'

For [out] and [in/out] parameters in the response it states;

'The return value accessor SHOULD be first, followed by the accessors for
the parameters which SHOULD be in the same order as they appear in the
procedure or method signature.'

Why the inconsistency? I think we should say the same thing for both 
and response. I don't have a *strong* opinion about whether we should
enforce order or not, but I'd tend to lean toward lining up the response
description with the description of the request.



Received on Friday, 8 February 2002 23:58:40 UTC