Gopi, So ultimately this is the SAME ugly issue that I identified last week WRT namespace handling in XMLBeans and particularly default namespace - e.g. it should NOT care about the value of the URL for the namespace declaration - but it does - and explicitly forces it to be a fixed value.
: -( What has happened here is that java has redefined what xml namespace handling is - at variance to the W3C definition - and essentially forced use of namespace prefixes regardless because simple well-formed XML does not work any more. Needless to say this cuts against the whole original design philosophy behind XML in the first place. The sequence goes something like this: 1) You start using simple well-formed XML content - but it errors out because somewhere some java complains that it does not have a default namespace declaration. 2) You attempt to remedy this by putting in a default namespace declaration - but this then triggers further undesired behaviours in java, either adding extraneous prefixes ns1: ns2: ns3: etc to elements, or simply rejecting the namespace declaration because it does not match some underlying schema declaration. 3) Your only recourse is then to festoon all your elements with namespace prefixes, thus negating why you were looking to use simple well-formed xml in the first place - and causing failures now from other software that is not expecting these prefixes and declarations. It would be nice if XMLBeans had a plain-simple-XML mode that did not trigger all these "features". I was looking to xmlOptions() to allow me to turn off all off these things selectively - but seems like we're not quite there yet... Thanks, DW -----Original Message----- From: gopi.rcr [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 28, 2006 2:00 PM To: user@xmlbeans.apache.org Subject: 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:[EMAIL PROTECTED] > Sent: Monday, November 27, 2006 5:19 PM > To: user@xmlbeans.apache.org > 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: user@xmlbeans.apache.org >> 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: 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] >> >> --------------------------------------------------------------------- >> 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
