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

Hi Jacek,

I think I like the direction of your proposal. However it would be 
easier to determine if you could provide a redlined version of the text 
rather than a set of diffs and then diffs to those diffs ;-).

Thanks,
Marc.

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.
> 
>  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
> 
> 
> 


-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

Received on Tuesday, 9 April 2002 09:28:38 UTC