RE: Issue with soap-rpc:result

Jacek,

I don't see this as a WSDL issue. While I understand that SOAP doesn't
*mandate* the use of XSD as a way to describe RPC methods, I would hope
that it would also *support* the use of XSD for this purpose. 

>  In fact, your problem comes from using XML Schema to describe 
> messages created with SOAP Encoding.

So the SOAP 1.2 RPC model in implicitly tied to SOAP Encoding?

The spec says:

"As noted above, RPC invocation and response structs can be encoded
according to the rules in 4 SOAP Encoding, or other encodings can be
specified using the encodingStyle attribute (see [1]Encoding
Attribute)."

I take that to mean that I can use the SOAP RPC model with no encoding
(encodingStyle=""). If that is true, it seems like I should be able to
use XSD to do what I want.

But your statement that I'm trying to describe a message created by SOAP
Encoding suggests that the spec (or my interpretation of it) is
inaccurate. Does that mean that I have to choose between the RPC model
(which mandates an encoding) and the use of XSD as a way to describe
message formats?

> 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-)

I favor XSD over SOAP Encoding simply because I believe that a) we need
to start from a standard wire contract and work out to our respective
programming languages and b) we already have XSD as a langauge for
describing formats of XML messages and we don't need to create a new one
for SOAP messages.

My *strong* hope is that the WSDL working group will not be *forced* to
move away from XSD simply to support SOAP 1.2's RPC model, especially
when there are SOAP toolkits out there today that support describing RPC
endpoints using XSD (e.g., Iona's XMLBus and Microsoft's ASP.NET). We've
waited a long time to get all these pieces in place and it seems like
SOAP 1.2 and XSD ought to play well together.

While I'm willing to walk away from SOAP Encoding in favor of schema,
I'd like to comply with as much of the rest of the SOAP spec as
possible, including the RPC model. But I want to be able to define my
messages in XSD (totally independent from WSDL) and if I have to give up
the RPC guidelines (or more likely follow all but the one about result)
to do that, I will.

Thanks,
Tim-



> 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 12:14:46 UTC