[prev in list] [next in list] [prev in thread] [next in thread]
List: xmlbeans-dev
Subject: RE: validate problem
From: "Eric Vasilik" <ericvas () bea ! com>
Date: 2004-09-23 0:48:52
Message-ID: 4B2B4C417991364996F035E1EE39E2E10D8F29 () uskiex01 ! amer ! bea ! com
[Download RAW message or body]
The exception you get on parse is not really a parsing exception. It's
an exception related to the fact that the incoming XML is not really a
DataDocument (this exception is only thrown from parse methods on
generated factories). What Dmitri suggests will work if the document
element is <data> and you substitute namespaces. However, of the
document element which comes in happens not to be data, or happens to be
qualified and matched a type on your path, you will not get a
DataDocument.
To force the XmlObject to be a specific type without the possibility of
getting this exception, you may want to use the DOCUMENT_TYPE option
with the DataDocument schema type when you call
XmlObject.Factory.parse(). This way, no matter what the real type of
the incoming document seems to be, it will be a DataDocument. Now,
whether or not the document is valid with respect to DataDocument is
another thing.
- Eric
-----Original Message-----
From: Dmitri.Colebatch@toyota.com.au
[mailto:Dmitri.Colebatch@toyota.com.au]
Sent: Wednesday, September 22, 2004 5:36 PM
To: dev@xmlbeans.apache.org
Subject: RE: validate problem
David,
Yep - what I was suggesting is more aimed at the problem where you
needed
to do multiple mappings. However you might also want to know that
XmlObject.Factory.parse() will return an implementation of the
appropriate
interface (ie DataDocument.Data) if that's what the XML is.
cheers
dim
-----Original Message-----
From: Baer, David M [mailto:D1Bw@pge.com]
Sent: Thursday, 23 September 2004 9:34 AM
To: dev@xmlbeans.apache.org
Subject: RE: validate problem
Dimtri,
Yes, that would work. Great suggestion.
In my case, however, I truly needed a DataDocument object, not a general
XmlObject. Once massaged (i.e., namespace qualification added), an
XmlObject could have provided the source for a DataDocument object to
parse, of course. But the XmlCursor manipulation would have been a bit
of
unwelcome work as well. Fortunately, the setLoadSubstituteNamespaces
trick circumvented the problem with very little additional code for the
case I was dealing with.
However, Hero, if he's still with us in this thread, may want to
consider
what you're suggesting. I think it would be an effective way to deal
with
the obstacles he's facing.
Thanks.
-----Original Message-----
From: Dmitri.Colebatch@toyota.com.au
[mailto:Dmitri.Colebatch@toyota.com.au]
Sent: Wednesday, September 22, 2004 4:21 PM
To: dev@xmlbeans.apache.org
Subject: RE: validate problem
David,
Instead of
DataDocument.Factory.parse("<Data><Details/></Data>");
try
XmlObject xml =
XmlObject.Factory.parse("<Data><Details/></Data>");
you can then use xml.newCursor() and cursor.setQName(...) to modify the
XML.
cheers
dim
-----Original Message-----
From: Baer, David M [mailto:D1Bw@pge.com]
Sent: Thursday, 23 September 2004 9:04 AM
To: dev@xmlbeans.apache.org
Subject: RE: validate problem
Eric,
The test case I was basing my comments on is irretrievable. However,
here
is a hastily constructed example that pretty much behaves the same way.
First the schema:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="testns" xmlns="testns"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:element name="Details"/>
<xs:element name="Data">
<xs:complexType>
<xs:sequence>
<xs:element ref="Details"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Running this code:
DataDocument xxx =
DataDocument.Factory.parse("<Data><Details/></Data>");
results in the following exception:
com.bea.xml.XmlException: error: The document is not a Data@testns:
document element namespace mismatch expected "testns" got ""
at com.bea.xbean.store.Root.verifyDocumentType(Root.java:501)
at com.bea.xbean.store.Root.autoTypedDocument(Root.java:417)
at com.bea.xbean.store.Root.loadXml(Root.java:1038)
at com.bea.xbean.store.Root.loadXml(Root.java:1028)
at com.bea.xbean.store.Root.loadXml(Root.java:1048)
at
com.bea.xbean.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.jav
a:200)
at testns.DataDocument$Factory.parse(Unknown Source)
Now, the following code gets through the parse without raising any
exception:
XmlOptions xo = new XmlOptions();
HashMap m = new HashMap(1);
m.put("", "testns");
xo.setLoadSubstituteNamespaces(m);
DataDocument xxx = DataDocument.Factory.parse("<Data><Details/></Data>",
xo);
Is that what you were looking for?
-----Original Message-----
From: Eric Vasilik [mailto:ericvas@bea.com]
Sent: Wednesday, September 22, 2004 2:34 PM
To: dev@xmlbeans.apache.org
Subject: RE: validate problem
Can you give me an example of XML which fails to parse? An unqualified
element name is something like <foo>. I can see if your schema defines
a
global element "foo" and has a target namespace, that validating this
element will fail, but parsing should succeed. All that the
setLoadSubstituteNamespaces does is change the names of elements as the
document loads, it does not do anything to help malformed XML parse.
Please know what validation and parsing are two totally separate things.
Validation does not happen when XmlBeans parses a document.
- Eric
-----Original Message-----
From: Baer, David M [mailto:D1Bw@pge.com]
Sent: Wednesday, September 22, 2004 11:16 AM
To: dev@xmlbeans.apache.org
Subject: RE: validate problem
The issue has to do with XML documents that, for whatever reason, have
no
namespace qualification. We need to load these into XmlBeans but we
can't
get parse to work due to the unqualified element names present in the
document where qualified names are called for by the schema.
When I ran into this, I came across the technique using
setLoadSubstituteNamespaces (where the map had a single entry providing
a
namespace designation for ""), which solved the problem. Hero, who
started this thread, had a tougher problem in that (as I understand it)
there were more than one namespace involved, so the
setLoadSubstituteNamespaces trick is no good in his case.
You made the comment that you could make these changes (manipulating
qnames) using XmlCursor, but I couldn't see how to get by the parse in
this case. I was simply trying to find out if you knew of an
alternative
to get through the parse operation so that the XmlCursor manipulation
you
mentioned could be pursued.
Thanks.
-----Original Message-----
From: Eric Vasilik [mailto:ericvas@bea.com]
Sent: Wednesday, September 22, 2004 9:40 AM
To: dev@xmlbeans.apache.org
Subject: RE: validate problem
In XmlBeans, we separate parsing and validation. It was my
understanding
that you had problems with validation. My point was that there are
several schemes for modifying the document before validation
happens: before, during or after parsing. What is causing the parse to
fail for you?
-----Original Message-----
From: Baer, David M [mailto:D1Bw@pge.com]
Sent: Wednesday, September 22, 2004 8:33 AM
To: dev@xmlbeans.apache.org
Subject: RE: validate problem
>try walking through the XML after it has been parsed
Eric,
Maybe I'm missing something fundamental here, but isn't the parse where
we
run into the problem? One can do all kinds of nifty (and maybe
foolhardy) manipulations with XmlCursor once the document is "loaded
up",
of course.
The problem I ran into (when trying to load a non-namespace qualified
document from a legacy source) prevented me from getting past a
successful
parse. In my case, where only one namespace was involved, the XmlOption
with setLoadSubstituteNamespaces nicely did the trick.
But before I discovered that technique, I didn't see any alternative but
to manipulate the incoming document prior to the parse, using some
non-Xmlbeans-based approach.
I'm not suggesting there's a deficiency in Xmlbeans, and
setLoadSubstituteNamespaces is painless enough to use if there's just a
single namespace involved. I'm simply trying to find out if there's an
alternative technique I've overlooked.
Thanks.
-----Original Message-----
From: Eric Vasilik [mailto:ericvas@bea.com]
Sent: Tuesday, September 21, 2004 8:28 PM
To: dev@xmlbeans.apache.org
Subject: RE: validate problem
You can try walking through the XML after it has been parsed, and
changing
the names of the elements as you see fit. You will want to use the
XmlCursor interface, getting the name of the elem/attr in question,
creating a new qname with the same local part, but with the desired
namespace, and then calling setName on the same elem/attr.
Alternativel, you could load the xbean with the SAX interfaces,
filtering
the sax events yourself. You will have to use your own sax parser,
intercept events, determine what namespaces the elems/attrs should have,
then pass the filtered events onto the sax loader XMlbeans supplies
(call
newXmlSaxHandler to get the Content and Lexical handlers).
- Eric
-----Original Message-----
From: Baer, David M [mailto:D1Bw@pge.com]
Sent: Tuesday, September 21, 2004 3:32 PM
To: dev@xmlbeans.apache.org
Subject: RE: validate problem
>Don't you think I will still run into the validation problem for
elements that belong to some different namespace?
Probably so. I missed your comment about different namespaces. I
happened to have this code open in front of me when your email came in,
so
I just shot it off to you without rereading your initial post.
The only other trick I can think of is some brute force string
replacement
in the incoming XML, which is not elegant and potentially inaccurate.
Hopefully someone with more expertise can provide a better solution.
-----Original Message-----
From: hero Smith [mailto:heroneedshelp@yahoo.com]
Sent: Tuesday, September 21, 2004 3:26 PM
To: dev@xmlbeans.apache.org
Subject: RE: validate problem
David,
Thanks for your email. I was thinking of doing some thing like that but
as
I mentioned in my earlier email different elements in the schema are
associated with different namespaces. If I do like what you have
suggested, I think it will replace all the elements with the same
namespace. Don't you think I will still run into the validation problem
for elements that belong to some different namespace?
--- "Baer, David M" <D1Bw@pge.com> wrote:
> You can do it with something like the following code, which tells the
> parser to use a supplied namespace if one is
> lacking:
>
> String s = "<...your XML document...>"; String ns = "your.name.space";
> XmlOptions xo = new XmlOptions(); HashMap m = new HashMap(1);
> m.put("", ns); xo.setLoadSubstituteNamespaces(m);
> SomeDocument x =
> SomeDocument.Factory.parse(s, xo);
>
> Hope that helps.
>
>
> -----Original Message-----
> From: hero Smith [mailto:heroneedshelp@yahoo.com]
> Sent: Tuesday, September 21, 2004 2:04 PM
> To: dev@xmlbeans.apache.org
> Subject: RE: validate problem
>
> Hi,
>
> Thank you for your email. Today, I got chance to look over this more
> carefully and found out that it was not the array problem. Sorry about
> that. However, I do have a question for you related to my actual
> problem.
>
> My problem is related to namespace. The schema that I am working is
> provided by some another team and they do have a namespace on it but
> when they actually send me the response, the response does not have
> any namespace information. This is why xmlbeans is complaining.
>
> Is there any way that I can say xmlbeans not to care about namespace
> during validation?
>
> If I cannot do so, is there any other good way to replace the elements
> in the response with namespace before I validate them?
>
> Different elements in the response may belong to different namespaces
> so how can I actually find that and replace them with appropriate
> namespace when the response don't have any namespace information at
> all.
>
>
> --- Radu Preotiuc-Pietro <radup@bea.com> wrote:
>
> > Hello,
> > This is the first time I hear about any problems
> validating arrays, I
> > think xmlbeans can validate them properly.
> > Unfortunately you don't offer enough detail for me
> to give any
> > meaningful explanation of what's happening; is
> there a minOccurs
> > alongside the maxOccurs?
> >
> > Radu
> >
> > -----Original Message-----
> > From: hero Smith [mailto:heroneedshelp@yahoo.com]
> > Sent: Saturday, September 18, 2004 9:47 PM
> > To: dev@xmlbeans.apache.org
> > Subject: validate problem
> >
> >
> > Hi,
> >
> > I am trying to validate the parsed xmlObject and
> for some reason the
> > xmlbeans keeps on showing error saying that it
> expects a particular
> > element. That element is an array in my schema
> with maxoccurs ="10"
> > and in my sample file it is there one time. Is it
> that xmlbeans cannot
>
> > validate array structure properly?
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@xmlbeans.apache.org
> > For additional commands, e-mail:
> > dev-help@xmlbeans.apache.org
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@xmlbeans.apache.org
> > For additional commands, e-mail:
> > dev-help@xmlbeans.apache.org
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile phone.
> http://mobile.yahoo.com/maildemo
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail:
> dev-help@xmlbeans.apache.org
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail:
> dev-help@xmlbeans.apache.org
>
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
######################################################################
DISCLAIMER:
This email and any attachment may contain confidential information.
If you are not the intended recipient you are not authorized to copy or
disclose all or any part of it without the prior written consent of
Toyota.
Opinions expressed in this email and any attachment are those of the
sender and not necessarily the opinions of Toyota.
Please scan this email and any attachment for viruses.
Toyota does not accept any responsibility for problems caused by
viruses,
whether it is Toyota's fault or not.
######################################################################
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
######################################################################
DISCLAIMER:
This email and any attachment may contain confidential information.
If you are not the intended recipient you are not authorized to copy
or disclose all or any part of it without the prior written consent
of Toyota.
Opinions expressed in this email and any attachment are those of the
sender and not necessarily the opinions of Toyota.
Please scan this email and any attachment for viruses.
Toyota does not accept any responsibility for problems
caused by viruses, whether it is Toyota's fault or not.
######################################################################
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic