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:[EMAIL PROTECTED] > Sent: Monday, November 27, 2006 5:19 PM > To: [email protected] > 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:[EMAIL PROTECTED] >> Sent: Monday, November 27, 2006 1:51 PM >> To: [email protected] >> 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:[EMAIL PROTECTED] >>> Sent: Wednesday, November 22, 2006 5:51 PM >>> To: [email protected] >>> 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: [email protected] >>>> 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: [email protected] >>>> 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] >> >> --------------------------------------------------------------------- >> 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#a7569291 > 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#a7585296 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]
