Ajith, If we send or receive soap message which is rpc-encoded, the xml fragment 2 can be possible. SOAP 1.1's soap encoding uses unqualified accessor element in compound type. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383519 I think this is the case for #2.
Also,, I suppose, we can find real world legacy soap use cases which use unqualified no-namespace XML even in document style web services. I think the this kind of legacy usages are not recommended and even wrong, but it is better that Axiom(Axis2) can handle these cases. Thought? ----- Original Message ----- From: "Ajith Ranabahu" <[EMAIL PROTECTED]> To: <[email protected]>; "jayachandra" <[EMAIL PROTECTED]> Sent: Thursday, March 03, 2005 8:33 PM Subject: Re: [Axis2] OMElementImpl question > 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 >
