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
