RE: [soapbuilders] Additional SOAP 1.2 tests redux
- Hi Bob, all:
On the SOAP 1.2 implementors conference call today, we discussed your "rpc-specific" issue with xmlp-7. We agreed that the purpose of this test was really to confirm that "env:Sender" matched up with HTTP 400, and that there are other tests to verify that bad arguments in RPC generate the correct subcode. Hence, we've removed the "RPC-ness" from the test as follows:
-------- new text for xmlp-7 ---------
The Node A sends echoSenderFault request to the Node C and the Node C
returns a fault with a value env:Sender for Code and an HTTP status
code with a value of 400 Bad Method.
An example of the request is:
-------- / new text for xmlp-7 ---------
(we just removed the part about "rpc:BadArguments")
We hope this is better / more flexible for you.
Ok, great, I've gone ahead and implemented tests xmlp-7 (echoSenderFault)
and xmlp-8 (echoReceiverFault) as non-rpc operations.
Have you looked at xmlp-10 (echoSimpleTypesAsStructOfSchemaTypes)?
It remains unimplemented here because I think that an operation using the
rpc convention doesn't make sense. I don't think I explained my misgivings
very well in my last post, so please allow me to try again.
I understand that xmlp-10 is testing conformity to SOAP 1.2 part 2 sec.
3.1.4 and specifically tests the assertion "Implementation supports
assigning type names to graph nodes." The graph nodes are those of the SOAP
Data Model and have a type name property that reflects the value of any
xsi:type AII found in the SOAP-encoded representation of the node.
The object of the test is that the XS type names of the members of an input
struct are to be echoed back in the return value. Since this test is using
the rpc convention, the SOAP encoded rpc invocation struct, once
deserialized into a SOAP Data Model graph, is then used to set up a
procedure call. This requires marshalling the input parameter value (a graph
node with children) into the procedure as a native type. This is the part
that concerns me... Section 4 of part 2 (SOAP RPC Representation) says that
the identities and values of arguments are passed to the procedure, but
there is no mention of XS type information being passed as well. Naturally
enough, I suppose, as in many environments it not at all possible. Using the
example of a C function with this signature:
int foo(char *in);
invoked using this SOAP rpc struct:
<m:foo xmlns:m="..."><in xsi:type="xsd:string">hello</in></m:foo>
Only the name and value of the input parameter are passed in to the
procedure. If the type name property from the corresponding SOAP Data Model
node doesn't go in, then of course it can't be passed back out in a return
value from the function. So it seems to me that test xmlp-10 expects the
impossible, by requiring that (XS) type names of input parameter graph nodes
be propagated through the native procedure call, at least for any
implementation in which XS Schema types need to be mapped to a different
type system for the purpose of RPC.
If xmlp-10 was instead an "echoGraph" operation, which used SOAP encoding
but didn't use the rpc convention, there would be no problem.
Does this make sense? Please set me straight if I'm missing something here.
>"rpc-specific" issue with xmlp-7. We agreed that the purpose of this test
> Hi Bob, all:
> On the SOAP 1.2 implementors conference call today, we discussed your
was really to confirm that "env:Sender" matched up with HTTP 400, and that
there are other tests to verify that bad arguments in RPC generate the
correct subcode. Hence, we've removed the "RPC-ness" from the test as
> -------- new text for xmlp-7 ---------
> method: echoSenderFault
> The Node A sends echoSenderFault request to the Node C and the Node C
> returns a fault with a value env:Sender for Code and an HTTP status
> code with a value of 400 Bad Method.
> An example of the request is:
> <m:echoSenderFault xmlns:m="http://soapinterop.org/"/>
> -------- / new text for xmlp-7 ---------
> (we just removed the part about "rpc:BadArguments")
> We hope this is better / more flexible for you.
The idea was to have two WSDL files both defining the same port using
the same binding but one would take a different parameter than the
other, a string vs. an int, say. That way, both the server and the
client would properly interpret each their WSDL but they wouldn't be
able to talk to each other.
Anyway, as the problem seem to have been solved this may not matter
Henrik Frystyk Nielsen
>From: Bob Cunnings [mailto:cunnings@...]
>Sent: Thursday, January 02, 2003 11:48
>AFAICS, 60.1 and 60.2 (xmlp-11 and 12) don't present any
>problems, and do cover the "Sender" fault case.
>By "two WSDL documents" do you mean defining separate document
>and rpc style operations for these tests? That would be
>possible, or separate ports (and bindings) for the two styles
>could be contained in a single WSDL doc.