RE: blank namespace

Very good!

DW

-----Original Message-----
From: gopi.rcr [mailto:gopi.rcr@xxxxxxxxx] 
Sent: Wednesday, November 29, 2006 2:07 PM
To: user@xxxxxxxxxxxxxxxxxxx
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:radup@xxxxxxx] 
> Sent: Tuesday, November 28, 2006 4:44 PM
> To: user@xxxxxxxxxxxxxxxxxxx
> 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:webberd@xxxxxxxxxx] 
> Sent: Tuesday, November 28, 2006 11:21 AM
> To: user@xxxxxxxxxxxxxxxxxxx
> 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:gopi.rcr@xxxxxxxxx]
> Sent: Tuesday, November 28, 2006 2:00 PM
> To: user@xxxxxxxxxxxxxxxxxxx
> 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: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.
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> ---------------------------------------------------------------------
> 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#a7605773
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