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: user@xmlbeans.apache.org
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?:
<xsd:element name="shape" type="shape"/>
<xsd:complexType name="shape" abstract="true">
<xsd:sequence>
<xsd:element name="length" type="xsd:double" minOccurs="0"/>
<xsd:element name="width" type="xsd:double" minOccurs="0"/>
<xsd:element name="radius" type="xsd:double" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="circle_restrict" abstract="true">
<xsd:complexContent>
<xsd:restrict base="shape">
</xsd:restrict>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="circle">
<xsd:complexContent>
<xsd:extension base="circle_restrict">
<xsd:element name="radius" type="xsd:double" minOccurs="1"
maxOccurs="1"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
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 <[EMAIL PROTECTED]> 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 <xs:group
ref="ArrestingGearPropertyGroup"/> 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
<[EMAIL PROTECTED]> 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:
> >
> > <xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema";
> > elementFormDefault="qualified"
> > attributeFormDefault="unqualified">
> >
> > <xs:element name="ArrestingGearTimeSlice"
> > type="ArrestingGearTimeSliceType">
> > </xs:element>
> >
> > <xs:complexType name="ArrestingGearTimeSliceType">
> > <xs:complexContent>
> > <xs:extension
base="AbstractAIXMTimeSliceBaseType">
> > <xs:sequence>
> > <xs:group
ref="ArrestingGearPropertyGroup"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> >
> > <xs:group name="ArrestingGearPropertyGroup">
> > <xs:sequence>
> > <xs:element name="description"
type="xs:string" nillable="true"
> > minOccurs="0"/>
> > </xs:sequence>
> > </xs:group>
> >
> > <xs:complexType
name="AbstractAIXMTimeSliceBaseType" abstract="true">
> > <xs:complexContent>
> > <xs:restriction base="AbstractGMLType">
> > </xs:restriction>
> > </xs:complexContent>
> > </xs:complexType>
> >
> > <xs:complexType name="AbstractGMLType"
abstract="true">
> > <xs:sequence>
> > <xs:group ref="StandardObjectProperties"/>
> > </xs:sequence>
> > </xs:complexType>
> >
> > <xs:group name="StandardObjectProperties">
> > <xs:sequence>
> > <xs:element ref="description" minOccurs="0"/>
> > </xs:sequence>
> > </xs:group>
> >
> > <xs:element name="description" type="xs:int"/>
> >
> > </xs:schema>
> >
> > This is my output from scomp:
> >
> > [EMAIL PROTECTED]:~/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.ja
va:47:
> > xgetDescription() in
noNamespace.impl.ArrestingGearTimeSliceTypeImpl cannot
> > 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.ja
va:29:
> > getDescription() in
noNamespace.impl.ArrestingGearTimeSliceTypeImpl cannot
> > 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
> > [EMAIL PROTECTED]:~/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.
