Very good! DW
-----Original Message----- From: gopi.rcr [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 29, 2006 2:07 PM To: user@xmlbeans.apache.org Subject: RE: blank namespace I found following two approaches to be more simpler to resolve namespace problem. 1) I create a single schema for both request and response messages. ie <getEquityAccountDetails> would include elements present in the request as well as response. 2) wrap it under an extra element Eg: request: <requestMsg> <getEquityAccountDetails>............</getEquityAccountDetails></request Msg> response: <responseMsg> <getEquityAccountDetails>............</getEquityAccountDetails></respons eMsg> I guess I would stick with Option 1. Thanks, Gopi Webber, David (NIH/OD) [C] wrote: > > Radu, > > OK - we're still working on trying the fix you suggested - now I know it > can turn off the namespace handling in the parser directly - I have a > better sense of the options here. > > This stuff was never supposed to be this hard ; -) > > Thanks, DW > > -----Original Message----- > From: Radu Preotiuc-Pietro [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 28, 2006 4:44 PM > To: user@xmlbeans.apache.org > Subject: RE: blank namespace > > I am sorry for having to disagree and for keeping the thread alive. > > But since adding a default prefix declaration ("xmlns=...") changes the > name of the elements, I cannot see how XMLBeans can ignore it. If, on > the other hand, you don't need the "xmlns=...", then you should not have > it in your document, and XMLBeans will continue to process it as a > document without namespace uri. > > You should be able to use well-formed XML without namespaces, the only > restriction is that the generated getters/setters (being derived from > XMLSchema information) will only work if the document loosely matches > your Schema (so documents without namespaces would work with classes > generated from a Schema without targetNamespace). In addition to that > you can use untyped XML with XMLBeans easily, with the XmlCursor API or > using XPath or DOM. > > What you seem to be looking for, rather, is a mode where namespaces are > simply ignored (and xmlns=.... has no special meaning) which is why I > was suggesting trying to turn namespaces off in the parser directly. I > don't think we need an XmlOption for that. > > Thanks, > Radu > > -----Original Message----- > From: Webber, David (NIH/OD) [C] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 28, 2006 11:21 AM > To: user@xmlbeans.apache.org > Subject: RE: blank namespace > > 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] > > _______________________________________________________________________ > 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] > > --------------------------------------------------------------------- > 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#a7605773 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]
