Hi David,
I already have header info in my message. I didnt post the complete message.
My complete msg looks like this:

<soap-env:header>
     <action>getEquityAccountDetail</action>
</soap-env:header>
<soap-env-body>
       <getEquityAccountDetails>
                -----
                    request information.
                ----
       </getEquityAccountDetails>
</soap-env-body>

This is what our server expects for a request message. Header as such doesnt
contain any useful information related to query.  The response msg also has
a similar structure only difference being the contents of
<getEquityAccountDetails> are different.

Response msg would look like this:

<soap-env:header>
     <action>getEquityAccountDetail</action>
</soap-env:header>
<soap-env-body>
       <getEquityAccountDetails>
                -----
                    response msg (XML format)
                ----
       </getEquityAccountDetails>
</soap-env-body>



I am open to modify my schema if it is going to solve the issue.

Thanks,
Gopi





Webber, David (NIH/OD) [C] wrote:
> 
> Why don't you re-design your schema so its not so badly overloaded?
> 
> Seems simple to add a few parent elements to resolve all this - such as:
> 
> <Msg>
>   <Query>
>    <!- - Msg goes here -->
>   </Query>
>   <Response>
>    <!- - Msg goes here -->
>   </Response>
> </Msg>
> 
> Or if you don't like that - what about
> 
> <Msg>
>   <Hdr> my header stuff goes here for each Msg type </Hdr>
>   <Body>
>     <!- - Msg goes here -->
>   </Body>
> </Msg>
> 
> Seems like your original design for the xsd is what is giving you all
> the problems...
> 
> DW
> 
> -----Original Message-----
> From: gopi.rcr [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 22, 2006 5:51 PM
> To: user@xmlbeans.apache.org
> Subject: RE: blank namespace
> 
> 
> Radu,
> Thanks for the detailed explanation.
> 
> Now I understand why it is behaving the way it is behaving. 
> 
> Let me explain the problem that I am facing. The request and response
> XML
> message formats for our server dont have any namespaces for the XML
> elements. ie. they belong to a default namespace. 
>  
> eg: <GetEquityAccountDetail> is used for both request as well as
> response
> however the contents of this element are different for both request and
> response. 
> 
> If I run these two schemas through scomp tool, there will be namespace
> collisions. So, to get around this problem, I associated  "req" and
> "resp"
> prefixes for request and response messages respectively. Now, I have two
> issues.
> 
> 1) When I generate a request message, it puts a "req" prefix which is
> perfect. BUt our server doesnt like the request message if there is a
> namespace prefix. So, I use saveImplicitNameSpaces to get rid of "req"
> prefix but it puts blank namespace references to other elements. Though
> the
> message is semantically correct, our server fails to validate. Looks
> like
> our server uses some kind of string matching program( not sure ) to
> validate
> the request message. Please let me know if there is a better way of
> solving
> this.
> 
> <req:GetEquityAccountDetail xmlns:req="http://.....";>
>       <acccountNumber> </acccountNumber>
>       <productCode> </productCode>
>       <elementList> </elementList>
> </req:GetEquityAccoungDetail>
> 
> 
> 2) I hardcode the request message and get the following response from
> the
> server. 
> 
> <getEquityAccountDetail>
>         <serviceName>ElpsService</serviceName>
>         <action>getEquityAccountDetail</action>
>         <processingTime>117</processingTime>
>         <info>
>                 <accountNumber>65165104446500001</accountNumber>
>                 <productCode>LCA</productCode>
>                 <lineOfCredit> </lineofCredit>
>          </info>
> </getEquityAccountDetail>
> 
> 
> Now, my schema has "resp" name prefix for the response message. So,
> parsing
> would obviously fail since the response I got from the server doesnt
> have
> any namespace. So, I use the following options.
> 
>                       HashMap m=new HashMap();
>                       m.put("","http://service.wellsfargo.com/resp/";);
>                       opts.setLoadSubstituteNamespaces(m);
> 
> When I try to print the values for ServiceName, ProcessingTime and Info,
> it
> is printing null for all these values.
> 
>       
> xml.response.GetEquityAccountDetailDocument.GetEquityAccountDetail
> 
>                  gead=geadRespDoc.getGetEquityAccountDetail();
>                  System.out.println(" Service name in body
> "+gead.getServiceName());
>                  System.out.println(" processing time in body
> "+gead.getProcessingTime())
> 
> Could you please tell me what I am missing? 
> Please let me know if there is a bettwer way of handling this.
> 
> 
> 
> Thanks in advance,
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Radu Preotiuc-Pietro wrote:
>> 
>> Gopi and David,
>> 
>> This is not about namespace declarations, this is about the names of
>> elements in an XML document. In namespace-aware Schema processors
> (like
>> XMLBeans and mostly everyhing out there, except for some legacy apps),
>> each element or attribute has a name (or QName, qualified name) that
> is
>> composed of a namespace uri (which can be empty) and a local name.
>> 
>> Now, in XMLSchema too, each time elements or attributes are declared,
> a
>> name is also part of the declaration. The names declared in the
>> XMLSchema and the names present in the instance XML file have to match
>> in order for the document to be valid, and this is what XMLBeans tries
>> to ensure.
>> 
>> Now in gopi's example, that Schema declared an element with the name
>> (local [EMAIL PROTECTED] uri)
>> 
>> [EMAIL PROTECTED]://service..com/req/ (local
>> name=getEquityAccountDetail, namespace-uri=http://service..com/req/)
>> 
>> This element in turn is supposed to contain the elements
>> 
>> accountNumber@
>> productCode@
>> elementList@
>> 
>> This is why the original document looks the way it does. It is
> correct.
>> By setting setSaveImplicitNamespaces(m), you tell XMLBeans that the
>> prefix "" (the default prefix) is already associated to the
>> "http://service..com/req/";, so then XMLBeans, correctly again, doesn't
>> redeclare it, but then when it comes to the "accountNumber", this
>> element has to have an empty namespace-uri and the only way to achieve
>> this is to use an xmlns="" declaration. This is correct and fully
>> expected.
>> 
>> All I am trying to say is that we have to look at this is terms of
>> changing names for elements, not in terms of manipulating prefix
>> declarations. On the loading side, we have
>> .setLoadSubstituteNamespaces() which replaces a namespace uri with
>> another for each name in the document. But this, again, does not have
>> the ability to replace any namespace in the incoming document with
>> something, you have to tell it in advance what namespaces to expect.
> On
>> the saving side, there is no option like that, I guess users have
> found
>> it useful only for loading.
>> 
>> I really want to do my best to help here, what part of what I wrote
>> din't make sense?
>> 
>> Radu
>> 
>> -----Original Message-----
>> From: Webber, David (NIH/OD) [C] [mailto:[EMAIL PROTECTED] 
>> Sent: Wednesday, November 22, 2006 7:03 AM
>> To: user@xmlbeans.apache.org
>> Subject: RE: blank namespace
>> 
>> Yeah - this is related to what I've been complaining about for a week!
>> 
>> Handling of default namespace is the reverse of what you would expect.
>> 
>> What you try is putting a default namespace declaration on your root
>> element - <req:getEquityAccountDetail
> xmlns="http://banktrans/default/";>
>> 
>> Which will at least prevent it having to generate ones for you inside
>> your XML.
>> 
>> There should however be some way to tell XMLBeans to not require a
>> default namespace declaration - but so far I've not been able to track
>> down how...
>> 
>> DW
>> 
>> -----Original Message-----
>> From: gopi.rcr [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, November 21, 2006 7:03 PM
>> To: user@xmlbeans.apache.org
>> Subject: Re: blank namespace
>> 
>> 
>> Forgot to include,
>> 
>> My schema file looks somthing like this.
>> 
>> <xs:schema targetNamespace="http://service..com/req/"; 
>>        xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>> 
>> <xs:import schemaLocation="Elps_GetEquityData_Request1.xsd"/>
>>      <xs:element name="getEquityAccountDetail">
>>              <xs:complexType>
>>                      <xs:sequence>
>>                              <xs:element ref="accountNumber"/>
>>                              <xs:element ref="productCode"/>
>>                              <xs:element ref="elementList"/>
>>                      </xs:sequence>
>>              </xs:complexType>
>>      </xs:element>
>> </xs:schema>
>> 
>> The elements accountNumber, productCode and elementList dont have a
>> namespace.
>> 
>> Thanks,
>> 
>> 
>> 
>> gopi.rcr wrote:
>>> 
>>> Hi,
>>> 
>>> I have an XMLBeans based program for generating XML output. XML
> output
>> 
>>> looks as below:
>>> 
>>> <req:getEquityAccountDetail>
>>>       <accountNumber>
>>>         <bank>651</bank>
>>>         <branch>651</branch>
>>>         <customer>0444650</customer>
>>>         <loan>0001</loan>
>>>       </accountNumber>
>>>       <productCode>LCA</productCode>
>>> -----------
>>> 
>>> When I modify my code to filter out req namespace prefix by doing the
>>> following.
>>> 
>>> XmlOptions op = new XmlOptions();
>>> HashMap m=new HashMap();
>>> m.put("","http://service.wellsfargo.com/req/";);  //namespace uri for
>> req
>>> opts.setSaveImplicitNamespaces(m);
>>> 
>>> -----------------------------------------------------------
>>> 
>>> I am getting output as follows, which has unwanted blank namespace
>>> references for accountNumber and ProductCode. What should I do to get
>> rid
>>> of these namespace references ? Why is it putting the blank namespace
>>> references ?
>>> 
>>> <getEquityAccountDetail>
>>>       <accountNumber xmlns="">
>>>         <bank>651</bank>
>>>         <branch>651</branch>
>>>         <customer>0444650</customer>
>>>         <loan>0001</loan>
>>>       </accountNumber>
>>>       <productCode xmlns="">LCA</productCode>
>>> 
>>> 
>>> You help is highly appreicated.
>>> 
>>> Thanks
>>> 
>>> 
>> 
>> -- 
>> View this message in context:
>> http://www.nabble.com/blank-namespace-tf2681769.html#a7482861
>> Sent from the Xml Beans - User mailing list archive at Nabble.com.
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>>
> _______________________________________________________________________
>> Notice:  This email message, together with any attachments, may
> contain
>> information  of  BEA Systems,  Inc.,  its subsidiaries  and
> affiliated
>> entities,  that may be confidential,  proprietary,  copyrighted
> and/or
>> legally privileged, and is intended solely for the use of the
> individual
>> or entity named in this message. If you are not the intended
> recipient,
>> and have received this message in error, please immediately return
> this
>> by email and then delete it.
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> 
>> 
> 
> -- 
> View this message in context:
> http://www.nabble.com/blank-namespace-tf2681769.html#a7497571
> Sent from the Xml Beans - User mailing list archive at Nabble.com.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/blank-namespace-tf2681769.html#a7565484
Sent from the Xml Beans - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to