Re: Issue with soap-rpc:result

 Tim,
 the intention is that the return value accessor is named 
soap-rpc:result _and_ strongly typed. If we remove the namespace 
qualification, we have to solve possible conflicts in this name 
and the names of the other accessors.
 In fact, your problem comes from using XML Schema to describe 
messages created with SOAP Encoding. This is one of the cases 
where XML Schema is not the perfect language for the job and 
where a different schema language would be better, something like 
SOAP Data Model Schema language. In that language you'd just say 
that this accessor is named {rpc namespace}result and typed to 
the proper type and there would be no problem. In XML Schema, you 
have to reference a different schema if you want to add an 
element from a different namespace.
 One simple solution that was proposed was that the RPC
convenction just mandate the unqualified name "result" (or
"SOAP-RPC-result") and say that no out parameter is named that. 
But resolving name conflicts is exactly what namespaces are for, 
we don't have to do funky SOAP-RPC-stuff to minimize the impact, 
we can just do a less funky soap-rpc:stuff that removes the 
problem. The fact that WSDL uses XML Schema to describe SOAP 
Encoding structures is, well, a problem of WSDL, not of SOAP 
Encoding or of SOAP RPC. We'll work on this in the WSDL working 
group. 8-)
 Best regards,

                   Jacek Kopecky

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



On Wed, 6 Feb 2002, Tim Ewald wrote:

 > All,
 > 
 > I want to raise an issue with the model for RPC invocations and
 > responses defined in Section 5, Using SOAP for RPC, of SOAP 1.2 Part 2
 > [1].
 > 
 > Specifically, mandating the "result" element from the
 > "http://www.w3.org/2001/12/soap-rpc" namespace as the accessor for an
 > RPC call's return value is problematic because that element is defined
 > as being of anyType.
 > 
 > Here's an example that illustrates the problem. Assuming I am using RPC
 > without any message encoding (which I believe is legal because the RPC
 > model doesn't mandate an encoding style).
 > 
 > Given this function:
 > 
 > int Add(int n1, int n2)
 > 
 > I could define the request and response messages this way:
 > 
 > <xsd:complexType name="Add">
 >   <xsd:sequence>
 >     <xsd:element name="n1" type="xsd:int" />
 >     <xsd:element name="n2" type="xsd:int" />
 >   </xsd:sequence>
 > </xsd:complexType>
 > 
 > <xsd:complexType name="AddResponse">
 >   <xsd:sequence>
 >     <xsd:element name="result" type="xsd:int" />
 >   </xsd:sequence>
 > </xsd:complexType>
 > 
 > However, the RPC model mandates the use of the predefined and untyped
 > result element, which suggests a response message schema like this:
 > 
 > <xsd:complexType name="AddResponse">
 >   <xsd:sequence>
 >     <xsd:element ref="soap-rpc:result"
 > xmlns:soap-rpc="http://www.w3.org/2001/12/soap-rpc" />
 >   </xsd:sequence>
 > </xsd:complexType>
 > 
 > The problem is that this is an extremely loose contract, the result
 > element can contain *any* XML. It would be possible for a SOAP node
 > generating an instance of this response message type to use xsi:type to
 > indicate the content model for the result element at runtime. However,
 > the use of xsi:type is not mandatory and presenting type information
 > only at runtime does not help people generating code to process messages
 > at development time.
 > 
 > The heart of this problem is (at least as I see it) an inconsistency in
 > the spec:
 > 
 > "Each parameter accessor has a name corresponding to the name of the
 > parameter (see A Mapping Application Defined Name to XML Name) and type
 > corresponding to the type of the parameter."
 > 
 > "The name of the return value accessor is "result" and it is
 > namespace-qualified with the namespace identifier
 > "http://www.w3.org/2001/12/soap-rpc"."
 > 
 > Why are parameters strongly typed while the return value is not?
 > 
 > I'd like to see the spec rewritten this way:
 > 
 > "Each parameter accessor has a name corresponding to the name of the
 > parameter (see A Mapping Application Defined Name to XML Name) and type
 > corresponding to the type of the parameter. The name of the return value
 > accessor is "result" and has a type corresponding to the type of the
 > return value. The return value accessor MUST be present if the return
 > value of the procedure is non-void. The return value accessor MUST NOT
 > be present if the return value of the procedure is void."
 > 
 > Thanks,
 > Tim-
 > 
 > [1] http://www.w3.org/TR/2001/WD-soap12-part2-20011217/#soapforrpc
 > 
 >

Received on Wednesday, 6 February 2002 11:12:55 UTC