Loading ...
Sorry, an error occurred while loading the content.

8960Re: [soapbuilders] Additional SOAP 1.2 tests redux

Expand Messages
  • Bob Cunnings
    Jan 4, 2003

      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.



      > 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
      > -------- 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.
      > --Glen
    • Show all 6 messages in this topic