[Fedora-suds-list] names/type confusion on nested elements

[Tim Butler]

I'm having a problem which, with my limited knowledge
of xml schema and soap, appears that suds is confusing
deeply nested element names with types. For all I know,
they should be equivalent and interchangeable, but my
Axis SOAP server says not.


  WSDL snippet:

     <schema targetNamespace="http://testme/model"
     xmlns="http://www.w3.org/2001/XMLSchema">
       <import namespace="http://schemas.xmlsoap.org/soap/encoding/" />

       <complexType name="ManagedEntityKey">
         <sequence />
       </complexType>

       <complexType name="TestKey">
         <complexContent>
           <extension base="tns1:ManagedEntityKey">
             <sequence>
               <element name="testId" nillable="true"
               type="xsd:string" />
             </sequence>
           </extension>
         </complexContent>
       </complexType>

     </schema>

  Marshalled request:

<SOAP-ENV:Envelope xmlns:intf="http://testme/intf" xmlns:SOAP-ENC="http://schema
s.xmlsoap.org/soap/encoding/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:
tns1="http://testme/model" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Header/>
    <SOAP-ENV:Body>
       <intf:retrieve>
          <in0 xsi:type="xs:string">NAME</in0>
          <in1 xsi:type="tns1:TestKey">
             <testId xsi:type="tns1:testId">TEST</testId>
          </in1>
       </intf:retrieve>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>


  Axis server gags with error:

    <faultstring>
    org.xml.sax.SAXException: No deserializer for {.../model}testId</faultstring>

But if I replace the type tns1:testId with xs:string in the raw request,
then the request succeeds using:

          <in1 xsi:type="tns1:TestKey">
             <testId xsi:type="xs:string">TEST</testId>
          </in1>

instead of:

          <in1 xsi:type="tns1:TestKey">
             <testId xsi:type="tns1:testId">TEST</testId>
          </in1>

I can provide the files to reproduce this if it is considered a suds defect.
Otherwise I suppose it is an axis defect if axis cannot recognize some equivalence
of tns1:testId to xs:string. If it is an axis defect then I need a suds hook
(which I have already desperately implemented) so I can
workaround the problem and substitute 'type' attributes on the raw request text or document.

Thanks

By the way, the current subversion release is parsing multiRefs from our Axis server
** THANK YOU **.

-tim