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

[Dan Sommers]

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).

> 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