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

 Pete, others,
 it seems I need to clarify that my email [1] contains *two* 
proposals:
 First (the first part) is just a clarification of the spec, 
mostly in the array representation.
 Second (the complete email) goes further - removing the terms 
return value (with its mandated name, obviously) and in/out 
parameter.

 I've believed that the first part is not controversial - it 
keeps the current name (rpc:result) for the return value edge in 
the struct case, it mandates that the return value edge is the 
first in the array case. That's it.

 More comments inside.

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0113.html



 > >(because in my optinion there really *is no distinction* between
 > >a return value and positional out parameters - they both don't
 > >have a name and it doesn't really matter whether you start
 > >counting the parameters from 0 or from 1). So effectively, this
 > >first part of my proposal has no notion of a return value.
 > >
 > That's arrays only. The same logic does not apply to structs which use 
 > name instead of position.

It was meant to be arrays only, this was rationale for how the
full (second) proposal understood the array case. (Actually, when 
writing the previous email, I was confused myself thinking that 
the first part of my proposal already removed the distinction 
between a return value and an out parameter.

 > > There were proposals to only specify the local name (but the
 > >possibility of various conflicts arises here which would have to
 > >be solved in the language bindings).
 > > There were proposals to keep the name in the application domain, 
 > >which is exactly what I've done in my full proposal.
 >
 > So who defines this name? Is it defined by the person writing the 
 > service? How does my code generator know that this is the return value 
 > and give the generated method the signature intended by the service 
 > author? Does that not matter (does it matter if it is generated as a 
 > return value or an OUT parameter?). It think it IS important to be able 
 > to identify the intended return value. If for no other reason than 
 > consistency. I don't want to be on a project that requires clients in 
 > java and .NET (to pick but 2) and one generates a client with a return 
 > value and the other generates, from the same definition, a method with 
 > no return value and a single OUT parameter.
 >
 > > I think either way (only first part or the full proposal) is an
 > >improvement over the current state, with the second part only
 > >going further in the direction of the first part. The first part 
 > >will not solve the issue 195, but that can be solved by saying 
 > >"we think mandating the full ns-qualified name is better than 
 > >only mandating the local name", please see my subsequent email on 
 > >this (it will have the subject "Issue 195: why not only specify 
 > >the local part" or something alike).
 > >
 > I have no argument with using a fully qualified name. I think that makes 
 > a lot of sense. I'm not actually sure what you are arguing any more 
 > putting these 2 mails together (I'm tired so maybe a reread of it 
 > tomorrow will help). Perhaps you could provide an example of what you 
 > mean for the java methods (i.e. what would the difference in their 
 > description or wire representation be?).
 > 
 >    void doSomething( OUT int value )
 > 
 > and
 >  
 >    int doSomething()
 > 
 > I am coming at this from an implementor's point of view rather than the 
 > higher level that most will  be looking at it from, and a fixed name 
 > makes a lot of sense to me. To this end I would agree that your term 
 > 'broken' describes the array representation case, and I am still 
 > struggling to see why there are 2 representations in the first place?


 In many languages (Java including) you don't have out 
parameters. On the other hand in C++ you can use a reference to 
int and that's an in/out parameter. So there's already one 
problem that language bindings of our RPC have to deal with and 
in which they cannot be consistent and still use the power of the 
languages.
 So same with the return value. When building a SOAP RPC service
from an existing code, you'd invent a name for the return value
out parameter (for example 'result' or 'returnValue' or
something). When building a client for an existing SOAP RPC
service, in absence of your customary return value out parameter
you could take the first out parameter in the ordering in which
they are mentioned in your service description (English, WSDL,
whatever) and treat that as the return value. You mustn't be
surprised if the parameters come in different order if they're in
a struct though.
 I don't see it important to be able to identify the intended
return value. In SOAP RPC the return value has no functionally
special meaning. For SOAP RPC it does not at all matter whether 
the modelled procedure does or does not have a return value, nor 
does it matter whether it does or does not have out parameters. 
I could imagine a special meaning of the return type if SOAP RPC 
faults were transmitted as special values of the return value. 
That's not the case though.
 In programming languages the return value mechanism is easier to
use, that's true. But in SOAP RPC, it's a complication. I think
the first part of my proposal (I'll send a slightly updated
version on its own, without the rest) is the best compromise.
 
Jacek

Received on Tuesday, 16 April 2002 11:40:37 UTC