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

8955RE: [soapbuilders] Additional SOAP 1.2 tests redux

Expand Messages
  • Henrik Frystyk Nielsen
    Jan 2, 2003
      Bob,

      I don't think there is any reason why xmlp-7, 8, and 10 should use RPC
      convention instead of doc/lit, especially as the former seems to be
      covered by 60.1 and 60.2 although I suspect that these may cause
      problems as well? If so, could these test cases be handled by having two
      WSDL documents that forced the fault to occur?

      Thanks for the feedback,

      Henrik Frystyk Nielsen
      mailto:henrikn@...

      * * * * *

      xmlp-7 (echoSenderFault), xmlp-8 (echoReceiverFault):

      SOAP messages representing RPCs result in the invocation of a native
      procedure in its normal runtime environment, outside the world of the
      SOAP processor. It is impossible for such a procedure to cause the
      generation of a SOAP fault other than indirectly. So at least in this
      implementation, these tests can't be supported. It's a different
      situation for doc/literal operations, it would be no problem, as an XML
      processing app has access to the SOAP environment at runtime and can
      generate any specific SOAP fault it wishes to. I hope this makes sense.
      I wonder if any other implementations would have similar problems.

      xmlp-10 (echoSimpleTypesAsStructOfSchemaTypes)

      This is similar to the situation above. This is an RPC operation, and
      the native procedure runs outside the SOAP environment, yet the test
      requires that the procedure have access to infoset stuff (types) from
      the original XML representation of the RPC. Of course the procedure is
      called with the parameter data, but it has already been deserialized to
      native types and XS type info is out of reach. Again, if it was a
      doc/literal operation, no problem.
    • Show all 6 messages in this topic