Re: Issue 195: soap-rpc:result

Herve Ruellan wrote:

> Jacek,
>
> Overall I agree with your analysis, but having a different point of 
> view I don't reach the same conclusion :-).
>
> My short reply to your short answer is: XML Schema is not suitable for 
> describing data in SOAP Data Model (or at least in SOAP Encoding), but 
> with a few tweaking, we should be able to used XML Schema to describe 
> data in SOAP Encoding for RPC requests and responses.
>
> I see three solutions:
>
> 1)
> We only specify the local name of the accessor for the return value.
>
> I agree that this might raise conflicts, but it is a compromise and as 
> such it is not a perfect solution.
>
> This local name can be:
> - 'result'
> - <remote procedure name>-result
> or anything similar.

I do not like this much better than specifying a complete accessor.

> 2)
> We do not specify the local name nor the namespace of the accessor for 
> the return value. Both are specified in the same place as the name of 
> the input and output parameters of the remote procedure.

To my mind, this is preferred by far.

> 3)
> RPC requests can be modeled as an array. If we change the spec and say 
> that in this case the namespace and local name of the accessor for the 
> return value are not specified, but that the return value is the first 
> element of the array, then there is no problem describing an RPC 
> response with XML Schema when it is modeled as an array. 

But if we insist on identifying the return value, the array result does 
not identify it, because you do not know that there actually was a 
return value -- they may have all been out parameters with a void return.

I think the fallacy is in insisting that the details of 
language-binding-specific signature be reflected in the soap service 
arguments.  The actual association of named or anonymous sent or 
received arguments with a language binding is a job for the language 
binding when it generates the language-adapted method signatures, which 
will be significantly different from one language to the next depending 
upon whether the language supports a return value, how (well) it 
supports out and in/out arguments, and whether the calling standard for 
that language associates passed parameters in an argument call by name, 
order, etc.

I certainly have language bindings being generated today that have no 
possibility of a return value other than another output argument.  It is 
not clear why SOAP should go beyond the simple natural organization of 
the struct or array.  I have no real problem with suggesting a name for 
the unimaginitive, but I will not take the suggestion myself, because I 
would much rather use the established practice for naming anonymous 
array members, which in this case works for the struct as well if you 
have a single anonymous member.  If forced to, I would prefer to name it 
as an output and then have the language binding associate it as a return 
value where appropriate, which I maintain it is free to do, but in this 
case the prescribed name has only confused things.

Ray whitmer
rayw@netscape.com

Received on Wednesday, 3 April 2002 12:21:33 UTC