axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jongjin Choi" <gunsn...@hotmail.com>
Subject Re: [Axis2] OMElementImpl question
Date Thu, 03 Mar 2005 12:29:49 GMT
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" <ajith.ranabahu@gmail.com>
To: <axis-dev@ws.apache.org>; "jayachandra" <jayachandra@gmail.com>
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 <jayachandra@gmail.com> 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
>
Mime
View raw message