Re: RPC Mapping

 Gudge,
 the original wording was that the parameters appear in the same 
order as in the function signature and that the return value 
accessor MUST be first. We cought that MUST in the RPC task force 
when we decided that the RPC element is modeled as a struct and 
that the return value accessor has a special name. The SHOULD is 
there to keep continuity.
 Now you caught that there is another, implied, MUST in the words 
"these appear in the same order ...", which I think we would have 
weakened to a SHOULD, too, if we caught it first in the RPCTF.
 We can try and remove the ordering stuff altogether but I think 
that what I suggest in the paragraph above is a satisfactory 
solution which keeps as much of the SOAP/1.1 rules as acceptable.
 What do others think?

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Fri, 8 Feb 2002, Martin Gudgin wrote:

 > In the editors copy of Part 2[1], section 4.1[2] states of [in] and [in/out]
 > 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 request
 > 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.
 > 
 > Gudge
 > 
 > [1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.xml
 > [2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.xml#IDAGG5CF
 > 

Received on Tuesday, 12 February 2002 05:16:10 UTC