Proposal for cleanup of RPC section (issue 195)

 Hello all. 8-)
 This is a proposal for cleanup of the RPC section in order to
clarify issues surrounding representation of parameters and the
naming of the return value. If accepted fully, this would solve
the issue 195 [2].

 First part of the proposal is not, I believe, controversial:
 It needs to be clarified that in the array representation of RPC 
result the return value is not named enc:result (because as we 
cannot specify positions in structs, we cannot specify names in 
arrays). Therefore I propose the sixth bullet in the RPC Body 
section - 4.1 [1] - to be split into:

 * Each outbound edge has a label corresponding to the name of
the parameter (see A Mapping Application Defined Name to XML
Name) or a position corresponding to the position of the
parameter. 

 * In the struct representation of the response, the label of the
return value outbound edge is "result" and it is
namespace-qualified with the namespace name
"http://www.w3.org/2001/12/soap-rpc". The return value outbound
edge MUST be present if the return value of the procedure is
non-void. The return value outbound edge MUST NOT be present if
the return value of the procedure is void.

 * In the array representation of the response, the return value 
outbound edge is the first member of the array if the return 
value of the procedure is non-void. The return value outbound 
edge MUST NOT be present if the return value of the procedure is 
void, therefore the first edge is the first [out] or [in/out] 
parameter.

 And the fifth bullet should be changed to:

 * The response is viewed as a single struct or array containing
an outbound edge for the return value and each [out] or [in/out]
parameter. If the response is an array, the return value edge
MUST be the first edge in the array.


 This is a clarification of the original intent when adding RPC
as arrays (as I perceive it) plus removal of the request (SHOULD)
for making the return value edge the first in a result struct.

 Now after some discussion with Ray Whitmer, I think we could do 
the following to fully close issue 195:

 1) in bullets 2 and 5 change the "[in] or [in/out]" and the
"[out] or [in/out]" to "[in]" and "[out]" respectively.  This
rids us of the term "[in/out] parameter" by pushing the possible
coupling of such parameters into a higher level.

 2) remove the term "return value" altogether: 

  2a) remove the latter two of the bullets which split from
bullet no. 6 (which effectively means that the bullet no.6 is
just trimmed)

  2b) change bullet 5 into "The response is viewed as a single
struct or array containing an outbound edge for each [out]
parameter."

 3) add a note somewhere which says: "Note: many languages have
the notion of a return value - an unnamed [out] parameter. Such
can be dealt with by inventing a name like 'result' or using the
array serialization of RPC result. Also some languages have
[in/out] parameters which can be dealt with as couples of [in]
and [out] parameters in SOAP RPC. None of this affects
interoperability."


 That's all. Other options I have considered (many of them
suggested by Ray) were
   i) trying to keep the return value by just some minor wording
changes in the current text; this would likely result in a bigger
confusion;
  ii) introducing a model for a procedure, complete with saying 
what [in], [out] and [in/out] parameters are and what a return 
value is; this would probably mean separating the array and 
struct models and disallowing using struct for request and array 
for response, for example;
 iii) using the generic compound type; (I didn't consider it 
really, I'm just listing it for completeness. 8-) )
  iv) dropping the RPC section.

                   Jacek Kopecky

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


[1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#rpcsoapbdy
[2] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x195

Received on Monday, 8 April 2002 14:34:29 UTC