Hi there, I suppose what you meant by the null prefix is the default namespace declaration. have a look at the following XML's and tell me if I have understood the problem correctly
xml fragment 1 <a xmlns="myns"> <b/> </a> in this case element b belongs to the namespace "myns" even though its is not prefixed. I believe this is the null prefix you were refering to. OM should support this behavior. xml fragment 2 <p:a xmlns:p="myns"> <b/> </p:a> in this case the namespace is prefixed and since b is not prefixed it is not namespace qualified. So OM will spit out an error message saying the elements are not ns qualified. I believe that case 1 should work. if it's not it's definitely a bug. i will run a test case and let you guys know On Thu, 3 Mar 2005 16:42:10 +0530, jayachandra <[EMAIL PROTECTED]> wrote: > Hi Axis2 developers, > Even I too am facing same problem. And, this appears like a bug to me. > As per SOAP element names should be qualified, but that doesn't > necessarily mean prefixes should exist. A default namespace element > may just be qualified with a null prefix. This should be fixed at the > earliest, or else interop is going to be a problem. > I am writing a CommonsHTTPTransporSender and am stuck in creating a response > response envelope out of the returned SOAP packet. In my case on the > server-side Axis1.2RC2 returned a SOAP packet (verified with tcpmon) > that has an element <EchoStringReturn>, this is being treated as > unqualifed and OM (AXIOM) is failing to (de)serialize it. > > Thank you, > Jayachandra > -- Ajith Ranabahu
