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

 Pete,
 first, there is no such thing as duplicate names in different 
namespaces. See [1], the namespace name is an integral part of 
the edge label.
 Second, the first part of my proposal [2] is meant to be only a
clarification of the spec, not any real change. I do think the 
spec needs such clarification.
 The proposal in its fulness was meant to address the issue 195 
by making things simpler (from my point of view) and more 
consistent.
 Last, the proposal you mentioned lower won't work becase in 
structs you can't say "the first edge". It would work if we had
   <env:Body>
     <m:getFoo rpc:returnEdgeRef="ret">
       <out1 id="ret">42</out1>
       <out2>foo</out2>
     </>
   </>
But this is not a SOAP Encoding struct (because of the 
attribute), and moving the rpc:returnEdgeRef into an element 
results in a situation equivalent to having rpc:result.

 So to clarify - my proposal [2] is to keep the fully qualified
name rpc:result for return value accessor or remove the notion of
a return value. My email you responded to was meant to say why we
should not accept the original proposal by Tim Ewald in issue 195
description.

 Best regards,

                   Jacek Kopecky

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

[1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#edgelabels
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0113.html



On Wed, 17 Apr 2002, Pete Hendry wrote:

 > 
 > >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 09:23:23 UTC