Hi Florian > > Humm, this is not really a good design to bound the XML > > Schema namespace > > to the default namespace and to a prefix, anyway it is allowed so it > > should work. > Oh I agree... as I said I have no control over the schema, other than > give my feedback to the author of the schema, which of course replied, > that its allowed by the standard and hence shouldn't be an issue....
And he is right, > > > According to XML Schema Recommendation part 2: the built-in datatypes > > must be in one of the following namespaces: > > > > http://www.w3.org/2001/XMLSchema > > > > or > > > > http://www.w3.org/2001/XMLSchema-datatypes for applications that just > > want to use XML Schema types. > > > > That's mean that 'string' must be bound to one those two > > namespaces and > > it is...the bug is in Castor. I've checked in a fix that allow reading > > your schema. > I've checked out the latest code from the CVS rep late last night and I > still get the same problem, even with a simple schema like this one: > > <schema > xmlns="http://www.w3.org/2001/XMLSchema"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://www.qwest.com/XMLSchema";> > <element name="ename" type="string"/> > </schema> > Are you sure you have recompiled the code? I've just tested your example and it is fine. I even have a CTF test case for it but I can't commit it yet since we are working on some modifications of the CTF. > > > Moreover your schema is not correct: a complexType cannot be the > > restriction of a simpleType, this schema is invalid. > Do you mean that Castor doesn't support this? No I mean your schema is not valid so Castor is right to report an error, >Because if I look at > the XML Schema Schema/DTD (http://www.w3.org/2001/XMLSchema.xsd or > http://www.w3.org/2001/XMLSchema.dtd) a complexType > can have a simpleContent element and a simpleContent element can have a > restriction element (from XMLSchema.xsd): > > <xs:complexType name="complexType" abstract="true"> > <xs:complexContent> > <xs:extension base="xs:annotated"> > <xs:group ref="xs:complexTypeModel"/> > [...] > </xs:extension> > </xs:complexContent> > </xs:complexType> > > <xs:group name="complexTypeModel"> > <xs:choice> > <xs:element ref="xs:simpleContent"/> > <xs:element ref="xs:complexContent"/> > [...] > </xs:choice> > </xs:group> > > <xs:element name="simpleContent" id="simpleContent"> > <xs:complexType> > <xs:complexContent> > <xs:extension base="xs:annotated"> > <xs:choice> > <xs:element name="restriction" type="xs:simpleRestrictionType"/> > <xs:element name="extension" type="xs:simpleExtensionType"/> > </xs:choice> > </xs:extension> > </xs:complexContent> > </xs:complexType> > </xs:element> > > So Castor doesn't support this? > ---------------------------------------------- <complexType name="IdentificationT"> <simpleContent> <restriction base="string"> <enumeration value="GenericId" /> <enumeration value="KeyCode" /> <enumeration value="CompositeKey" /> </restriction> </simpleContent> </complexType> ----------------------------------------------- Castor tries to support the XML Schema Recommendation as close as possible, here are some fragments of the spec: - Schema Representation Constraint: Complex Type Definition Representation OK 2. If the <simpleContent> alternative is chosen, the type definition .resolved. to by the .actual value. of the base [attribute] must be either a complex type definition whose {content type} is a simple type definition or, only if the <extension> alternative is also chosen, a simple type definition; In the above, the type definition resolve to by the value of the base attribute is not a complex type definition. - Schema Component Constraint: Complex Type Definition Properties Correct 2. If the {base type definition} is a simple type definition, the {derivation method} must be extension. In the above, the base type definition is a simple type definition, but the derivation method is restriction. - Schema Component Constraint: Derivation Valid (Restriction, Complex) If the {derivation method} is restriction all of the following must be true: 1. The {base type definition} must be a complex type definition whose {final} does not contain restriction. In the above, the derivation method is restriction, but the base type definition is not a complex type definition. Maybe there's a bug in the Schema for Schema but I don't think Castor interpretation is wrong, Arnaud ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
