Fun with web-services and unqualified elementFormDefault

Recently I was participating in writing client for document-style binding web-service. This is the first time I saw such wsdl in the field, so I immediately wrote a small test application in VS.NET 2005. Although invoke appears to be working normally, I got null response instead of some actual data. I spent a whole week blaming authors of the web service, but they convince me that the problem was on the client side. It was quite difficult to intercept soap messages, because they were using https, but I found an interesting post how you can get them from SoapHttpClientProtocol. Using this small hack, I was able to observe the resulting envelope, that did contains response, which looks legitimate. But at the end in the corresponding C# object I still got nulls. The wsdl begins with the following declaration:

<wsdl:definitions name="testservice"
     targetNamespace="http://www.testservice.com">
<wsdl:types>
 <xsd:schema elementFormDefault="unqualified"
      targetNamespace="http://www.testservice.com/test">
   <xsd:element name="response">
     <xsd:complextype>
       <xsd:sequence>
         <xsd:element name="ident" type="xsd:string">
         <xsd:element name="number" type="xsd:string">
       </xsd:sequence>
     </xsd:complextype>
....

Visual Studio generate me a corresponding class called response with 2 properties, that has Unqualified System.Xml.Serialization.XmlTypeAttribute. Apparently, Axis on the server side was sending me a message, where both ident and number was in http://www.testservice.com/test namespace, which contradicts with the schema definition above. This was the reason why deserialization from XML does produce nulls. At least this time Microsoft proofs to support standards better than Apache Foundation :)