Re: Issue 195: why not only specify the local name

>If we specify only the local name, there will be two levels of
>possible conflicts. Let's say we mandate that the local name of
>the return value edge is 'result'.
> The first conflict: what if we want to have a parameter called 
>result?
> Possible solution - the language binding can translate the name
>to _result and add an underscore in front of any other parameter
>name that starts with it. So "void foo(int result, int _other)"
>would result in a message with parameters named _result and 
>__other.
>
Not very practical obviously. I am reading from the latest draft and it 
specifies the return value MUST be called 'rpc:result' which makes more 
sense than local name only.

>
> The second conflict - if we have the contract specified in XML 
>Schema (or other XML schema language as opposed to specifying the 
>procedure signature), and we have two elements in the result 
>struct:
> <m:fooResult xmlns:m="urn:foo">
>   <a:result xmlns:a="urn:a"/>
>   <b:result xmlns:b="urn:b"/>
> </m:fooResult>
>
This does not address the issue of the return value but a more general 
issue of whether duplicate names in a struct will be supported (with 
different namespaces). There should be nothing wrong with defining

 <m:fooResult xmlns:m="urn:foo">
   <rpc:result xmlns:rpc="http://www.w3.org/2001/12/soap-rpc"/>
   <b:result xmlns:b="urn:b"/>
 </m:fooResult>

as the soap node would know that rpc:result is the 'unnamed' return 
value and treat it accordingly to prevent the local name conflict.

>
> This can be achieved if a language binding uses namespaces 
>instead of underscores.
> Possible solution - we can say that the struct can contain only 
>one edge whose local name is 'result'.
>
But not required if the FQN of result is fixed and can be identified by 
the processor and dealt with to prevent conflict.

>
> In effect, we'd be adding complexity in language bindins (in 
>most languages a parameter can be named 'result') and unnecessary 
>restrictions in the structs (going across all possible namespaces 
>which we shouldn't be able to affect) *only* because we want to 
>use an unsuitable language to describe SOAP RPC in the easy way. 
>I'd rather use the language in a slightly more complex way than 
>change SOAP here.
>
I don't think this adds any more restrictions on structs than are 
already present. How would a SOAP processor handle duplicate names in 
general when in different namespaces? It is not specific to result. 
Having a specific name for the result allows the soap processor to at 
least identify it as such and take action.

>
> A sketch of a possible solution for WSDL if we stick with the
>fully qualified name rpc:result (for those who wonder):
>
> <message name="getStockQuoteResult">
>    <part name="anything" element="tns:returnTypeElement"/>
> </message>
>
> <binding>
>   <operation name="getStockQuote">
>     ...
>     <output message="tns:getStockQuoteResult">
>       <soap12:returnValuePart name="anything"/>
>     </output>
>   </operation>
> </binding>
>
> And the returnValuePart would always be represented in the 
>resulting SOAP message as rpc:result, no matter it's original 
>name (tns:returnTypeElement).
>
My initial reaction to this was that I quite liked the idea. But, then 
thinking about it, I'm not sure it actually adds any value. If the name 
has to be mapped to rpc:result anyway, where would this mapping be done? 
It depends on where the processor has the WSDL available (at which 
level). Chances are it may apply the WSDL rules and then serialize the 
resulting graph. If this is the case then the name is transformed within 
the struct and the conflict again results where the struct is not 
supporting the multiple versions of result. This would force many 
processors to have to somehow hack in names to be substituted during 
serialization which gets messy or forces the processor to be written in 
a certain way that it cannot abstract the serialization completely away 
from the SOAP processing.

It also means that the resulting message is exactly as described now in 
the draft (2002/04/10) spec and so the spec would not have to change. 
What is presented in WSDL (as above) is not really any worry to the SOAP 
spec, only what ends up on the wire. If I understand correctly you are 
saying to leave the spec as it is currently as far as the wire content?

Sorry to be disagreeing all the time, but I quite like the way the 
struct response is currently in the draft spec.

I seem to recall someone posting a while back to soapbuilders with a 
proposal to use an attribute on the response method

 <env:Body>
   <m:mymethodResponse env:hasreturn="true" >
      <out1>xxx</out1>
      <out2>yyy</out2>
   </
 </

and, if it is true then the return value must be the first in the 
struct/array. This would work for both the array and struct case and the 
name would then not be significant in either case. I'm not proposing 
this as a great solution - I've just remembered it as I type - but at 
least it works for both array and struct and leaves no ambiguity in the 
message. Perhaps something along these lines ... ?

Pete

Received on Tuesday, 16 April 2002 08:52:08 UTC