[Fedora-suds-list] May Suds be introducing an extra level of indirection?

[Daniel Rodriguez]

Hi Jeff,

No need at all to apologise. I do understand that given the definition of
the WSDL and as you explain, data has to be accessed with:

   - result.bits.Bit[x]

But I have to admit that I find surprising that given the returned XML file,
Suds (and possibly other SOAP libraries) is able to recognize this
indirection and re-introduce the missing layer of indirection (according to
the WSDL definition)

Anyhow, thanks to Python's dynamic nature, it's easy to correct this by
doing: result.bits = result.bits.Bit

Thank you

Best regards

Daniel

On Fri, Apr 23, 2010 at 15:07, Jeff Ortel <jortel at redhat.com> wrote:

> Hey Daniel,
>
> Sorry for delayed reply :)  See below:
>
> -jeff
>
>
> On 04/16/2010 01:47 AM, Daniel Rodriguez wrote:
>
>> Hi Jeff,
>>
>> I am by no means a WSDL/XSD expert, but I think that Suds might be
>> introducing an extra level of indirection, although this can also be my
>> misinterpretation.
>>
>> Definition of a complex type in the WSDL file:
>>
>>    <xsd:complexType abstract="true" name="APIResponse">
>>    <xsd:sequence>
>>    <xsd:element name="header" nillable="true"
>>    type="types:APIResponseHeader"/>
>>    </xsd:sequence>
>>
>>    <xsd:complexType name="GetCurrentBitsResp">
>>    <xsd:complexContent>
>>    <xsd:extension base="types:APIResponse">
>>    <xsd:sequence>
>>    <xsd:element name="bits" nillable="true" type="types:ArrayOfBit"/>
>>    <xsd:element name="errorCode" type="xsd:string"/>
>>    </xsd:sequence>
>>    </xsd:extension>
>>    </xsd:complexContent>
>>    </xsd:complexType>
>>
>>    <xsd:complexType name="ArrayOfBit">
>>    <xsd:sequence>
>>    <xsd:element form="qualified" maxOccurs="unbounded" minOccurs="0"
>>                 name="Bit" nillable="true" type="types:Bit"/>
>>    </xsd:sequence>
>>    </xsd:complexType>
>>
>>    <xsd:complexType name="Bit">
>>    <xsd:sequence>
>>    <xsd:element name="size" nillable="false" type="xsd:double"/>
>>    <xsd:element name="remaining" nillable="false" type="xsd:double"/>
>>    </xsd:sequence>
>>    </xsd:complexType>
>>
>>
>> The returned XML looks like:
>>
>>    <n:Result xsi:type="n2:GetCurrentBitsResp">
>>    <header xsi:type="n2:APIResponseHeader">
>>       ...
>>    </header>
>>    <bits xsi:type="n2:ArrayOfBit">
>>    <n2:Bit xsi:type="n2:Bit">
>>    <size xsi:type="xsd:double">1.02</size>
>>    <remaining xsi:type="xsd:double">0.0</remaining>
>>    </n2:Bit>
>>    <n2:Bit xsi:type="n2:Bit">
>>    <size xsi:type="xsd:double">5.03</size>
>>    <remaining xsi:type="xsd:double">3.51</remaining>
>>    </n2:Bit>
>>    </bits>
>>    <errorCode xsi:type="xsd:string">OK</errorCode>
>>    </n:Result>
>>
>>
>> In the generated Python objects the ArrayofBit is accessible with:
>>
>>    * result.bits.Bit
>>
>> When I would expect (seeing the XML) to access the array with:
>>
>>    * result.bits
>>
>> Maybe you or any other with a better knowledge of WSDL and XSD could
>> clarify if this should be the case or not.
>>
>
> I understand your thinking here.  And, it's possible that what your
> expecting is what the author of the wsdl intended.  But, according to the
> xsd, the unbounded element (and thus the array) is bits.Bit.  The author
> made this too fancy and should have omitted the ArrayofBit stuff all
> together.  Had the schema been written like this:
>
>
>     <xsd:complexType name="GetCurrentBitsResp">
>     <xsd:complexContent>
>     <xsd:extension base="types:APIResponse">
>     <xsd:sequence>
>     <xsd:element name="bits"
>            nillable="true"
>            type="types:Bit"
>            maxOccurs="unbounded"
>            minOccurs="0"/>
>
>     <xsd:element name="errorCode" type="xsd:string"/>
>     </xsd:sequence>
>     </xsd:extension>
>     </xsd:complexContent>
>     </xsd:complexType>
>
> you would access as:
>
> result.bits[0], ....
>
> The key is which element is maxOccurs="unbounded".
>
>
>> Best regards
>>
>> Daniel
>>
>>
>>
>> _______________________________________________
>> suds mailing list
>> suds at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/suds
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/suds/attachments/20100424/dbefbb14/attachment.html