RE: blank namespace

David,
Given a choice, I would like to do it without resorting to a namespace
prefix. Looks like the moment I put targetnamespace into my schema, it
generates a prefix and applies it to all the elements which is right but the
problem is with our server which doesnt accept the request message.

Also, when we receive a response message, XMLBeans fails to parse it
correctly since the response msg doesnt have any namespace while our schema
does since xmlns is "this.one.is.inbound".

I cant use default namespace for both, since scomp tool detects conflicts
while generating java source files.

So, I guess, the only option I am left with is to assign some namespace and
strip it while sending it to the server. For response message received from
the server, prepend a namespace prefix to <GetEquityAccountDetail> tag so
that XMLBeans parses it correctly.

Thanks,
Gopi




Webber, David (NIH/OD) [C] wrote:
> 
> Gopi,
> 
> You are obviously going to have to break this apart as Radu indicated -
> to process the SOAP separately.
> 
> I still want to do this without having to resort to namespace prefixes
> and switching those - which seems clumsy and ugly.
> 
> Having structure variance between the in / out should allow you to
> distinguish between them via XPath expression - and alternate xsd
> definitions - all you then need is to have the two XMLBeans definitions
> so you can select the right one.
> 
> Since I noticed that XMLBeans is sensitive to the URL in the default
> namespace declaration - perhaps this can be used too?
> 
> e.g.
> 
> <Msg type="in" xmlns="this.one.is.inbound"/>
> 
> And 
> 
> <Msg type="out" xmlns="this.one.is.outbound"/>
> 
> And those URLs have to be declared in two different variants of your XSD
> in the target statements.
> 
> Your server I'm assuming will ignore the default xmlns declaration
> variance as its only interested in the well-formed XML.
> 
> DW
> 
> -----Original Message-----
> From: gopi.rcr [mailto:gopi.rcr@xxxxxxxxx] 
> Sent: Monday, November 27, 2006 5:19 PM
> To: user@xxxxxxxxxxxxxxxxxxx
> Subject: RE: blank namespace
> 
> 
> Thanks David for your quick response. 
> Even if I introduce one more header, I guess I am still going to have my
> basic problem of resolving name space collisions when I try to compile
> schemas into java files since <soap-env:header>, <soap-env:body>,
> <getEquityAcountDetails> etc tags will be present in all my request and
> response messages. 
> 
> Thanks,
> Gopi
> 
> 
> 
> Webber, David (NIH/OD) [C] wrote:
>> 
>> Gopi,
>> 
>> Yes - you need to modify your schema - make two choices for the
> elements
>> - and add a parent element above if necessary - so you can have two
>> forms of the child elements - depending on the type of message you are
>> sending.
>> 
>> This is what I was trying to tell you - add a type Hdr to YOUR MSG
>> perhaps is one choice - not the SOAP HDR!!!
>> 
>> Then inside your own header you can have two or more forms of the
>> elements you need.
>> 
>> DW
>> 
>> -----Original Message-----
>> From: gopi.rcr [mailto:gopi.rcr@xxxxxxxxx] 
>> Sent: Monday, November 27, 2006 1:51 PM
>> To: user@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: blank namespace
>> 
>> 
>> 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:gopi.rcr@xxxxxxxxx] 
>>> Sent: Wednesday, November 22, 2006 5:51 PM
>>> To: user@xxxxxxxxxxxxxxxxxxx
>>> 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 name@namespace uri)
>>>> 
>>>> getEquityAccountDetail@http://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:webberd@xxxxxxxxxx] 
>>>> Sent: Wednesday, November 22, 2006 7:03 AM
>>>> To: user@xxxxxxxxxxxxxxxxxxx
>>>> 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:gopi.rcr@xxxxxxxxx]
>>>> Sent: Tuesday, November 21, 2006 7:03 PM
>>>> To: user@xxxxxxxxxxxxxxxxxxx
>>>> 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: user-unsubscribe@xxxxxxxxxxxxxxxxxxx
>>>> For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxx
>>>> 
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxx
>>>> For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxx
>>>> 
>>>>
>>>
>>
> _______________________________________________________________________
>>>> 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: user-unsubscribe@xxxxxxxxxxxxxxxxxxx
>>>> For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxx
>>>> 
>>>> 
>>>> 
>>> 
>>> -- 
>>> 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: user-unsubscribe@xxxxxxxxxxxxxxxxxxx
>>> For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxx
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxx
>>> For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxx
>>> 
>>> 
>>> 
>> 
>> -- 
>> 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: user-unsubscribe@xxxxxxxxxxxxxxxxxxx
>> For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxx
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxx
>> For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxx
>> 
>> 
>> 
> 
> -- 
> View this message in context:
> http://www.nabble.com/blank-namespace-tf2681769.html#a7569291
> Sent from the Xml Beans - User mailing list archive at Nabble.com.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxx
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxx
> 
> 
> 

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