[Fedora-suds-list] Complex Return Types (Again?)

[Jeff Ortel]

On 11/19/2009 06:54 AM, Dan Sommers wrote:
> On 2009-11-18 at 17:29:00 -0600,
> Jeff Ortel<jortel at redhat.com>  wrote:
>
>> On 11/18/2009 02:44 PM, Dan Sommers wrote:
>
>> d = client.last_received()
>> s = str(d)
>
> That was my first try, and it worked smashingly until one of my users
> found some XML that contained an ampersand ("&") and a less than symbol
> ("<") within its text nodes.  Somewhere in there, suds decoded the
> entities twice, and str returned ill-formed XML (i.e., XML containing
> actual ampersands and less than symbols in its text nodes instead of
> "&amp;"s and "&lt;"s).

Ah, very interesting.  Let's fix this!  Can you send me sample XML that the suds sax 
package does not handle correctly?  Also, what version of suds are you using?

>
>> client.set_options(retxml=True)
>> d = client.service.foo()
>> s = str(d)
>
> That's what my code looks like now, but without that last string
> conversion (which apparently triggers that extra level of decoding?):
>
>      client.set_options( retxml = True )
>      s = client.service.foo( ... )
>      x = lxml.etree.XML( s )
>      ...
>
>> ... Also, won't you have the same problems with:
>> <snip>
>>> I'm having an awful time fixing up all of the namespaces and getting
>>> rid of the elements with xsi:nil="true" attributes.
>> </snip>
>> even if you had the raw string XML?
>
> My tactical mistake was prematurely extracting an XML fragment from the
> response and losing an essential xmlns attribute or three.  Oops.  ;-)
>
> So now I take the *whole* response (i.e., the soapenv:Envelope element)
> and run it through an XSL transform that pulls out the fragment I need,
> re-wraps that fragment in a new element, and removes elements with
> xsi:nil="true" attributes.  The namespace issue went away once I fixed
> my approach.
>
>> The exact XML (stream) returned by the server is consumed by the sax
>> parser (inline) and isn't really available.  To capture it, I would
>> have to read the entire document into memory then sax parse the
>> string.
>
> What you're doing is definitely the right approach (not that you need my
> approval!).  My use of the word "original" referred to the character
> entity issue I described above.
>
> Thank you, for both suds and your reply.
>
> Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5126 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/suds/attachments/20091119/dfd77a58/attachment.bin