Re: Issue 195: slightly updated simple proposal

I, too, prefer the proposal that ignores the special status of the 
return in the result message.  I only suggested adding a 
pseudo-output-argument which indicates which is the return because it 
seemed to be the way to add that information without harming other 
things.  If adding an attribute violates the model, it avoids that.  It 
just looks like another well-identified output argument.

Let me take a different approach to the discussion.

I assert that with two different types of RPC call and response -- array 
and struct -- it seems impossible to know which result is the return 
even using a fixed namespace/localname for the return.  This is because 
there seems to be no good way -- short of knowing the type of the return 
-- array or struct -- which will not be obvious since it is named after 
the object and the method.  While some may choose to attach and 
interpret the xsi:type, there are many who will likely prefer not to do 
this but rather to rely on a schema which indicates that the object is a 
subtype of one or the other.  I dislike xsi:type and think it should be 
possible to avoid it.

I think this is an argument that the binding cannot just ignorantly 
process the response without knowing about the call signature so knowing 
which is the return value does not help much independently.  As I have 
pointed out in the past, this is clearly the case in the named 
argument/struct when calling from most languages anyway since most 
languages pass arguments by position rather than value and the 
association cannot be made on-the-fly without knowing the names and 
positions of the arguments.

Ray Whitmer
rayw@netscape.com

Received on Friday, 26 April 2002 20:12:44 UTC