Re: Issue 195: slightly updated simple proposal

Since there has been apparently no more recent discussion, I will 
comment on this proposal.

This apparently does nothing whatsoever to resolve issue 195.  I find 
issue 195 to be a real concern.  I think it should be possible to use 
schema to accurately describe simple RPC calls.  If a struct has been 
chosen as the return vehicle, then if a fixed name with a fixed type is 
required, this is not possible.

There is nothing in the charter or in the requirements that lead me to 
believe that it is essential to know without knowing the method 
signature that a particular return value is a special unnamed return, 
which a language may or may not support.  There are so many other things 
that the binding is expected to understand or map arbitrarily, and SOAP 
1.2 has made this worse by making both a struct and an array as options 
because now every language, whether it supports named or positional 
arguments has to support calls that will be of the other type just 
because someone decided they should be.

How about the following language instead:

 * In the struct representation of the response, the label of the
unnamed return value outbound edge is the one which does not
correspond to any of the named out or in/out parameters.

In most languages you have to know the names of the parameters anyway, 
so they can be associated with positions, since few languages associate 
by name.  This way, the result is given a meaningful name and type, 
which is good for a variety of reasons.  This is also no worse than the 
case of a returned array where you do not know whether or not there is a 
return value unless you know the signature and binding.

Ray Whitmer
rayw@netscape.com


Jacek Kopecky wrote:

> Hi all, 8-)
> this is the first part of my former proposal [1], updated a 
>little and standing on its own so it's not so confusing.
> In short, the update removes the mandatory presence or absence
>of the return value in the struct representation, it adds a note
>about the array representation, and it does some rephrasing in
>places.
> The proposal:
>
> It needs to be clarified that in the array representation of RPC
>result the return value is not named rpc:result (because as we
>cannot specify positions in structs, we cannot specify names in
>arrays). Therefore I propose the fifth bullet to 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.
>
> And the sixth bullet in the RPC Body section - 4.1 [1] - should
>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".
>
> * 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. If the return value of the
>procedure is void, the first edge is the first [out] or [in/out]
>parameter.
> Note: in case the application designers only know the format of
>the messages, they are free to choose to treat the first out
>parameter as a return value or as the first out parameter.
>
> The note should probably go somewhere else than in the bullet, 
>but I don't know where, really.
>
>                   Jacek Kopecky
>
>                   Senior Architect, Systinet (formerly Idoox)
>                   http://www.systinet.com/
>
>
>
>[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0113.html
>
>

Received on Tuesday, 23 April 2002 18:28:26 UTC