I think your implementation is fine with multiple elements as the return, if the WSDL define
d it directly in that
way, but in the WSDL itself, the getSummary isn't defined as a series of simple elements, it
's defined as a
complex element consisting of the series of individual elements.

Gisle Aas wrote:

>  Mike McGurrin <mcgurrin@[...].org> writes:
> 
>  > I sent a message similar to the following to ActiveState's response
>  > email, and they suggested I post it to this mailing list.  I hope that
>  > it is appropriate.
> 
>  Yes it is.
> 
>  > I have downloaded and tried out the Python "beta" demo of the WebService
>  > API.  First, I'm looking for any documentation on what's implemented and
>  > what's not with respect to SOAP and this?  I've tried it out, really
>  > like the concept (and we're doing projects in Python, hence my interest in the Python
>  > implementation of the WebService API), but found a fair number of the
>  > web services listed at Xmethods returned errors.
>  >
>  > For instance, while most of Cape Clear's airport weather service works
>  > fine with it, getSummary doesn't.  My guess is because
>  > getSummary returns a complex type.  Anyone know if this is correct?
> 
>  Yes, that is correct.  It returns this kind of response:
> 
>  SOAP-ENV:Envelope
>          xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
>          xmlns:xsd="http://www.w3.org/1999/XMLSchema"
>          xmlns:cc1="http://www.capeclear.com/AirportWeather.xsd"
>          xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
>          xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
>          <SOAP-ENV:Body
>                  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
>                  <cc2:getSummaryResponse
>                          xmlns:cc2="capeconnect:AirportWeather:com.capeclear.weatherstation
.Station"> 
>                          <return  xsi:type="cc1:WeatherSummary">
>                                  <location  xsi:type="xsd:string">Williams Field, Antarctic
a</location> 
>                                  <wind  xsi:type="xsd:string">from the NW (320 degrees) at 
4 MPH (4 KT)</wind> 
>                                  <sky  xsi:type="xsd:string">mostly clear</sky>
>                                  <temp  xsi:type="xsd:string">8 F (-13 C)</temp>
>                                  <humidity  xsi:type="xsd:string">60%</humidity>
>                                  <pressure  xsi:type="xsd:string">29.2 in. Hg (988 hPa)</pr
essure> 
>                                  <visibility  xsi:type="xsd:string">greater than 7 mile(s)<
/visibility> 
>                          </return>
>                  </cc2:getSummaryResponse>
>          </SOAP-ENV:Body>
>  </SOAP-ENV:Envelope>
> 
>  I don't really understand why our soapy does not grook this.  I'll
>  take a look.
> 
>  >  I do know that Soapy (which the demo is based on) doesn't currently
>  > support complex types.
> 
>  Not completely.  Sometimes it does.  Looks like it has problems with
>  this service though.
> 
>  > Also, it fails with many of the Microsoft .Net servers.  My guess is
>  > because they reference the 2001 schema version in the namespace
>  > definitions, and the client uses 1999 and declares an error when it sees
>  > 2001.
> 
>  We have already patched in support for XML Schma 2000/10 and 2001.
> 
>  > Is the Python implementation at ActiveState undergoing active
>  > development?
> 
>  Not really.  We fix obvious bugs as we find them, but we will probably
>  not try to do any fancy enhancements with the current code base.  As
>  you noted, soapy itself appears to be dead.  We used it because it was
>  the fastest way to get the simples part of the API up running so that
>  sample clients can be written.
> 
>  The future is probably something that is based on ZSI.
> 
>  Regards,
>  Gisle Aas,
>  ActiveState

_______________________________________________
Ws-dev mailing list
Ws-dev@[...].com
http://listserv.ActiveState.com/mailman/listinfo/ws-dev