Re: AXIS/SOAP Interop Test Summary

[Sam Ruby <ru...@us.ibm.com>]

Rich Scheuerle Jr wrote:
>
> The number of red failures in the last run: 35
> The number of red failures in the jan 1 run: 41

Great work!

> Void (SoapX4 and TclSoap both return elements with no values)

Open question: should we accept these resposes?

We accept an response containing an empty envelope from eSOAP.  We don't
accept the one from TclSOAP because it is explicitly marked as a an
xsd:int.  We don't accept the response from SoapX4 because there is
whitespace between the begin tag and the end tag.

> Hex Binary (4s4c and 4s4c2.0 both return soapenc:base64)

Open question: we do automatic conversions in other cases (example: vector
=>array).  Should we consider doing the same thing here?

> Also there are more SOAP structArray problems.  Without the wire dumps
> its hard to tell what is going on, but I suspect that SOAP is now sending
> the arrays across with a type=ArrayOfSOAPStruct instead of
> type=soapenc:Array.

What is currently sent by Apache SOAP is accepted by a large number of
other end points.  In fact, with your fixes, we now accept
ArrayOfSOAPStruct in a response.  Is there any reason that we shouldn't
accept the same thing in a request?

> SOAP may need to apply the same fix that I did to the array serializer to
> force type=soapenc:Array.

Should this be forced?  It seems to me that ArrayOfSOAPStruct is not only
legal, but more specific (in oo terms, a subtype).  On the other hand,
forcing it to may increase interop.  On the other other hand (whoops! hand
fault.), forcing it makes it impossible to generate a whole class of legal
SOAP messages.

- Sam Ruby