Hi Axis2 Developers! Has it been taken care of in Axis2 to (de)serialize non-qualifying objects too. Kindly update the group when it's done and where from can the new source be gotten.
Thank you, Jayachandra On Thu, 3 Mar 2005 21:29:49 +0900, Jongjin Choi <[EMAIL PROTECTED]> wrote: > 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 > > -- -- Jaya
