On 03/06/14 06:44, Stefan Behnel wrote:

It's easier if you only need it on the modifyResponse tag, as it'll simply end up on the first element that defines it. If you need it on both, lxml's internal namespace declaration cleanup will make that difficult, because it heavily tries to avoid duplication of namespace declarations.

For what it's worth, this kind of thing is unfortunately quite common. There's a lot of really, really horrific XML processing code in the wild that clearly isn't using an actual XML parser under the hood (ditto generation). Being able to explicitly control this kind of thing would be very handy for crapware interop ;o) As it is, I tend to cheat and set dummy attributes in the places I want specific stuff to be, then postprocess the generated XML e.g. doc = E.tag( E.child( E.value('text', nshere="foo_urn:...") ) ) docstr = etree.tostring(doc) docstr.replace('nshere="foo_', 'xmlns:foo="') Yes, I know - utterly vile :o(

Yes but I also tried a couple of things and couldn't find a way to trick lxml to add a redundant xmlns declaration. I can't think of any other way to make this work.

For the record, it's possible to set the bogus attribute on ctx.out_document in a method_return_document event and performing the replace operation on ctx.out_string in a method_return_string event.

http://spyne.io/docs/2.10/reference/service.html#spyne.service.ServiceBase http://spyne.io/docs/2.10/reference/application.html#spyne.application.Appli...

That's pretty slick and convenient. I'll give that a whirl if I fail to simply reorganize the declarations. I am pretty sure at this point I cant place all the blame on the client. I suspect it rips out the payload then unmarshalls it at which point that declaration is not present. Instead of duplicating it, I can probably let lxml do its thing and refrain from declaring that one to early. Thank everyone! jlc

On 03/06/2014 17:30, Burak Arslan wrote:

On 03/06/14 16:00, Joseph L. Casale wrote:

...

I am pretty sure at this point I cant place all the blame on the client. I suspect it rips out the payload then unmarshalls it at which point that declaration is not present.

Well I'm pretty sure you definitely should, though :) Whatever your client does with the tree, it must not forget where these tags come from.

But some clients do. They're badly written, don't comply with the XML spec, and the vendors don't acknowledge the problem, let alone fix it. When this software is widely embedded in expensive devices that can't be replaced, you have to deal with the reality, not the ideal situation :o(