Hi : I am trying to use XML Beans with the AIXM schema as well. I am seeing similar problems. I realize there are certain problems with the AIXM schema that users are not able to change. I am building web services and all other tools seem to not work when trying to map aixm xml to java objects.
I was wondering if you were able to resolve this? Thanks Ash Lux wrote: > > Thank you for pointing me to the right place in the specs. I'm glad to > hear > the silly shape example is fine. > > I'll submit an issue to both XMLBeans and AIXM on this. > > Thanks for the help. > > On 3/14/08, Radu Preotiuc-Pietro wrote: >> >> Exactly, in your original example the Schema is invalid and XMLBeans has >> a bug for not reporting the condition sooner. This is the paragraph of >> the >> spec that I was referring to: >> >> http://www.w3.org/TR/xmlschema-1/#cos-ct-extends >> >> Clause 1.5 is clearly not satisfied by your original example. If the >> Schema in error comes from a 3rd party you can easily point out to them >> (politely :-) that the Schema is invalid, if you have the chance (and in >> the >> meantime, you need to use a local modified copy). If you control one of >> the >> Schemas involved, then you need to change the Schema that you do control. >> >> The "shape" example on the other hand, I believe it's all right, because >> the "radius" element has the same type (xsd:double) in both places and >> the >> minOccurs="1" in the derived type is a restriction of minOccurs="0" in >> the >> original type. >> >> I know this is not the easiest part of XMLSchema to understand, but if >> you >> think about it, I believe it makes sense. >> >> Hope this helps, >> Radu >> >> ------------------------------ >> *From:* Ash Lux [mailto:[email protected]] >> *Sent:* Friday, March 14, 2008 6:14 PM >> *To:* [email protected] >> *Subject:* Re: scomp error - incompatible return type >> >> Thank you Jacob and Radu for the help. >> >> Unfortunately I'm not the one who controls the schema - it's one of >> "define a schema by a large committee thing". I'm sure that explains a >> lot. >> :-) I'll certainly try and get the schema fixed, but I don't want to >> accuse >> them of having a bad schema when XMLBeans has a bug. >> >> Radu is tihs what you're talking about being invalid?: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> maxOccurs="1"/> >> >> >> >> >> I am doing something similar to this with a schema I do control. When >> using XMLBeans, the Circle class will have getters and setters for >> radius, >> length, and width but if you try to set anything other than radius the >> object will not validate (actually XMLBeans might throw an exception, I >> don't quite remember). This seems to be the correct behavior from what I >> understand (which might not be much). >> >> In the above example, XMLBeans overrides Circle_Restrict's getRadius >> method and replaces it with its own. >> >> So in my original example the ArrestingGearTimeSliceType class is trying >> to override AbstractGMLType's getDescription method (with a int return >> type) >> as implement it's own getDescription (with a string return type). >> >> It looks to me XMLBeans has a bug one way or another - either the schema >> is valid and XMLBeans is blowing up on compile or XMLBeans isn't catching >> the invalid schema and blowing up on compile. If this is a valid schema, >> there's not really a pretty solution XMLBeans can use.. >> >> On 3/13/08, Radu Preotiuc-Pietro wrote: >> > >> > Having an element called "description" of type "int" does sound fishy >> to >> > me, so I suggest you change that to "string". >> > >> > I seem to vaguely remember that there is a Schema rule according to >> > which you can't remove an element by restriction and then in a >> > subsequent derivation step, add it back by extension, which is what is >> > happening here. If my recollection is correct, then there is a bug in >> > XMLBeans for not catching this error sooner. If not, then it is just a >> > Java limitation (are you compiling with jdk1.5 or 1.4?) >> > >> > Radu >> > >> > >> > On Thu, 2008-03-13 at 11:00 -0700, Jacob Danner wrote: >> > > As far as whats going on, ArrestingGearTimeSlice has 2 description >> > > elements defined >> > > 1 from xs:extension base="AbstractAIXMTimeSliceBaseType" which refers >> > > to the top level description as an int >> > > and the other from which >> > > refers to its local type description as a string. >> > > >> > > I'm not really sure whats intended by the aixm group here, but it >> > > appears to be a valid error (one I would expect) from the schema >> > > snippet you posted. >> > > You may want to contact aixm about it. >> > > If you can tell us what is expected from that type, maybe we can hack >> > > up a real workaround for you, but the simplest thing I would suggest >> > > is to change those types to match. >> > > -jacobd >> > > >> > > On Thu, Mar 13, 2008 at 6:06 AM, Ash Lux wrote: >> > > > I've been trying to use a third party's XSD with XMLBeans >> > (specifically >> > > > something called AIXM - http://www.aixm.aero/). >> > > > >> > > > I'm unsure if the problem lies with XMLBeans or with the schema. I >> > was able >> > > > to replicate the problem with this test XSD: >> > > > >> > > > > > > elementFormDefault="qualified" >> > > > attributeFormDefault="unqualified"> >> > > > >> > > > > > > type="ArrestingGearTimeSliceType"> >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > nillable="true" >> > > > minOccurs="0"/> >> > > > >> > > > >> > > > >> > > > > abstract="true"> >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > This is my output from scomp: >> > > > >> > > > ash...@ashlux-work:~/Desktop$ ~/java/xmlbeans-2.3.0/bin/scomp >> > test.xsd >> > > > Time to build schema type system: 2.25 seconds >> > > > Time to generate code: 0.621 seconds >> > > > >> > /tmp/xbean41513.d/src/noNamespace/ArrestingGearTimeSliceType.java:29: >> > > > xgetDescription() in noNamespace.ArrestingGearTimeSliceType clashes >> > with >> > > > xgetDescription() in noNamespace.AbstractGMLType; attempting to use >> > > > incompatible return type >> > > > found : org.apache.xmlbeans.XmlString >> > > > required: org.apache.xmlbeans.XmlInt >> > > > org.apache.xmlbeans.XmlString xgetDescription(); >> > > > ^ >> > > > >> > /tmp/xbean41513.d/src/noNamespace/ArrestingGearTimeSliceType.java:24: >> > > > getDescription() in noNamespace.ArrestingGearTimeSliceType clashes >> > with >> > > > getDescription() in noNamespace.AbstractGMLType; attempting to use >> > > > incompatible return type >> > > > found : java.lang.String >> > > > required: int >> > > > java.lang.String getDescription(); >> > > > ^ >> > > > >> > >> /tmp/xbean41513.d/src/noNamespace/impl/ArrestingGearTimeSliceTypeImpl.java:47: >> > > > xgetDescription() in >> noNamespace.impl.ArrestingGearTimeSliceTypeImplcannot >> > > > implement xgetDescription() in noNamespace.AbstractGMLType; >> > attempting to >> > > > use incompatible return type >> > > > found : org.apache.xmlbeans.XmlString >> > > > required: org.apache.xmlbeans.XmlInt >> > > > public org.apache.xmlbeans.XmlString xgetDescription() >> > > > ^ >> > > > >> > >> /tmp/xbean41513.d/src/noNamespace/impl/ArrestingGearTimeSliceTypeImpl.java:29: >> > > > getDescription() in >> noNamespace.impl.ArrestingGearTimeSliceTypeImplcannot >> > > > implement getDescription() in noNamespace.AbstractGMLType; >> > attempting to use >> > > > incompatible return type >> > > > found : java.lang.String >> > > > required: int >> > > > public java.lang.String getDescription() >> > > > ^ >> > > > Note: Some input files use or override a deprecated API. >> > > > Note: Recompile with -Xlint:deprecation for details. >> > > > 4 errors >> > > > >> > > > BUILD FAILED >> > > > ash...@ashlux-work:~/Desktop$ >> > > > >> > > > It appears as if the schema is violating the unique particle >> > attribution >> > > > rule, but I'm not sure because of the restriction tag. If I do not >> > use the >> > > > group tag, I get the unique particle attribution rule. >> > > > >> > > > Got any thoughts on what's going on? Any thoughts on workarounds >> or >> > hacks? >> > > > >> > > >> > > >> > > >> > >> > >> > 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] >> > >> > >> >> 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. >> > > -- View this message in context: http://www.nabble.com/scomp-error---incompatible-return-type-tp16028037p21613559.html Sent from the Xml Beans - User mailing list archive at Nabble.com.
