Re: Proposal for cleanup of RPC section (issue 195)

Jacek,

I like very much your proposal.

What I would prefer is that we agree to your full proposal, that is by 
accepting 1), 2) and 3).

If not, I can live with only taking the first part of it. To make it 
clearer, I have some small editorial comments (see below).

Thank you,

Hervé.

Jacek Kopecky wrote:
>  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.

To be more precise, and to have this bullet closer to the struct's one, 
I would change the first sentence to:

"In the array representation of the response, the return value outbound 
edge MUST be the first edge in the array and MUST be present if the 
return value of the procedure is non-void.".

>  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 Tuesday, 9 April 2002 04:01:25 UTC