Re: RPC Style Issues (3)

Umit Yalcinalp wrote:
> Sanjiva,
> 
> Sanjiva Weerawarana wrote:
> 
>>"Umit Yalcinalp" <umit.yalcinalp@oracle.com> writes:
>>  
>>
>>>>I think this is the key on this issue.  Do we care if an RPC style WSDL
>>>>      
>>>>
>>can come out with two different signature?
>>  
>>
>>>> void f([out] int x)
>>>> int f()
>>>>
>>>>      
>>>>
>>
>>That's a design choice in languages that support out parameters
>>and hence the person defining the language binding for such
>>languages need to make the choice.
>>
>>+1 to Jack's comments.

+1. It's not up to WSDL to define language bindings.

>>>(1) Being able to designate a void return as well as designating an
>>>output parameter as the return value (your example).
>>>    
>>>
>>
>>I think this is going too far - its one thing to support RPC
>>signatures but its another to support all possible combinations
>>in all languages.
>>
>>We can support a way to indicate a return value. There can be out
>>parameters. If a language binding wishes to make the return
>>value an out parameter that's its business. Think Pascal vs. C
>>vs. C++ vs. Java - there are different "right" answers. (I don't
>>know enough about C#'s rules.)
>>
> No. Our current rules force one to accept the first out param as the 
> return value. That is not acceptable because there are two signatures to 
> support. Void return can not be supported with the current rule.

Last week we made a distinction between testable requirements triggered
by the RPC style, i.e. making sure that the input/output messages have
the appropriate form, and hints for processors. The association between
a given RPC-style operation and a function signature (informally
defined, btw) is in the hint bucket, so there is no implication that
language bindings should respect it.

Now that I clarified this, I don't have an issue with allowing
additional attributes to be used to provide further hints. Actually,
I don't see how we could disallow this even if we wanted to.

>>>(2) Allowing SOAP rpc return value convention to coexist in the RPC style.
>>>    
>>>
>>
>>Definitely -1 for this. We cannot make the abstract RPC style rules
>>SOAP specific. SOAP, IMO, has gone way overboard in allowing
>>dynamic indication of the "return value" concept. There's no way
>>I'm going to support that for WSDL abstract RPC signatures.

-1 from me too.

>>>The WG can make an explicit decision not to allow (2). Lets not mix the
>>>two.
>>>
>>>I would like to solve problem (1). We should decide whether (2) is
>>>acceptable or not, but (1) must be solved and yield two different
>>>signatures. This is NOT a 80/20 problem. From our perspective, they both
>>>exist and *are* different.
>>>    
>>>
>>
>>Language binding can make that decision - its not up to us.
>>
> 
> 
> This is not a language binding issue. It is impossible to have two 
> different signatures. Tom's example is simple and clear. We need to be 
> able to recognize both cases as separate signatures. With the current 
> rules, there is only one mapping. Mapping to a void return value is not 
> possible. Period.

If this use case is important enough to users of the RPC-style, then
I guess it's OK to standardize some way to convey the necessary
information.

>>>I propose another approach to solve (1) which was mentioned but not
>>>clearly spelled out in my message starting this thread.
>>>
>>>-- Define an attribute "result" in the rpc namespace. Its value is a
>>>    
>>>
>>QName.
>>  
>>
>>>-- Use the attribute in the output element to designate the return value
>>>in the output message (body) itself.
>>>
>>><interface name="whatever" ...>
>>>     <operation name="foo" pattern="..."
>>>style="http://www.w3.org/@@@@/@@/wsdl/style/rpc" >
>>>        <input.../>
>>>        <output messageReference="..."
>>>                     body="..."
>>>                     rpc:result="tns:myValue"/>
>>></interface>

This seems fine. rpc:result is a well-defined extension attribute.

>>>-- If the attribute does not exist, then there is no return value. You
>>>infer that it is void.

And this goes in the hint bucket, right?

>>>-- It is an error to have this attribute in the output element when the
>>>style is not rpc.

This doesn't sound right. The rpc:result extension can be ignored
by a processor without harm, and the spec for the RPC style cannot
state any requirements that apply when it is NOT used. On the other
hand, it'd be OK to say in the spec for the rpc:result extension that
it MUST be used in conjunction with the RPC style. Then processors
that are rpc-extension-aware will be able to flag the case you describe
as an error.

Thanks,
Roberto

Received on Tuesday, 28 October 2003 14:07:34 UTC