Daniel Ruoso wrote:
Just try to send any XML with namespace information and you should see it happening, like: <SOAP-ENV:Envelope xmlns:SOAP-ENV="..."> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Bla bla bla</faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>would become<Envelope xmlns="..." SOAP-ENV="..."> <Body> <Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Bla bla bla</faultstring> </Fault> </Body> </Envelope> The problems here are: * xmlms:SOAP-ENV became simply SOAP-ENV... which is a non-existant attribute * faultcode and faultstring were unqualified elements and now are declared as being of the SOAP-ENV namespace * renaming the prefixes is not a recommended practice, and, in fact, you need to understand the specific XSD to do it, since QName types (the SOAP-ENV:Server value) care about the prefix.
While I agree that there are some bugs here, it seems like even if we did preserve the prefixes your faultcode and faultstring elements would be in the wrong namespace, because the default namespace within the XMPP stream is jabber:client, jabber:server or whatever.
Is there something else we need to do here to make faultcode and faultstring work as expected? I'm not really familiar with SOAP iself, let alone SOAP over XMPP, so if I'm misunderstanding what's going on here please let me know... I just want to make sure that we are indeed addressing all of the prefix-related problems.
