Hi, Thanks very much for your detailed posting. We are indeed interested in making sure the Castor SOM is as accurate as possible. Like you some users simply choose Castor XML for this feature alone.
May I propose you raise this bug in our JIRA system? This will give us a place to work together on patches that resolve these issues. Once we have some patches I'll be more than happy to review them before committing them for you into the code base. http://jira.codehaus.org/browse/CASTOR Many Thanks, Andrew Fawcett -----Original Message----- From: Post, Dr. Ulrich [mailto:[EMAIL PROTECTED] Sent: 19 October 2005 17:15 To: dev@castor.codehaus.org Subject: [castor-dev] Bugs in XML Schema Model ? Hi I have just started to evaluate the XML Schema Model of Castor 0.9.9. In the past I have implemented an XML schema processor using C++. During that time I did a lot of reading in the XML schema recommendation. Meanwhile, I'm looking for a schema model implemented in Java. When looking more closely at the schema model created by the SchemaReader, I found some results which look like inconsistencies with the XML schema spec. If I did not miss something, they might deserve to be fixed before the final release. Before going into details: (1) seems to be a severe bug in conjunction with schema composition and namespace handling and there is no simple workaround (2) seems to be a severe bug when using a hierarchy of complex types with attributes (3) deals with a very special and probably even exotic case At least for fixing (1) some modifications in org.exolab.castor.xml.schema.Schema are required - maybe I could assist on that. Best regards Uli (1) Namespace handling =================== Various unqualified references to named global objects without a namespace are not resolved correctly. This affects usage of the following attributes which have a type QName as of the Schema for Schemas: - ref (used in attribute, element, group, attributeGroup) - type (used in attribute, element) - base (used in restriction, extension) - substitutionGroup (used in element) - itemType (used in list) So far, I have not tested all these scenarios, only the following - <xs:element ref="..."> - <xs:attribute ref="..."> - <xs:attribute ... type="..."> - <xs:attributeGroup ref="..."> - <xs:group ref="..."> The following example illustrates the bug for <xs:attribute ref="...">: withTNS.xsd <xs:schema targetNamespace="NS1" xmlns:xs="http://www.w3.org/2001/XMLSchema";> <xs:import schemaLocation="./noTNS.xsd"/> <xs:attribute name="A1" type="xs:date"/> <xs:element name="E1"> <xs:complexType> <xs:attribute ref="A1"/> </xs:complexType> </xs:element> </xs:schema> noTNS.xsd: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> <xs:attribute name="A1" type="xs:time"/> </xs:schema> As there is no namespace declaration for the default namespace in withTNS.xsd, the QName value of the ref attribute in <xs:attribute ref="A1"/> is {-,A1}, i.e. without any URI. Hence, it should resolve to attribute A1 as declared in noTNS.xsd. Unfortunately, when calling attrDecl.getReference() for the attrDecl constructed from <xs:attribute ref="A1"/>, the global attribute declaration for A1 in withTNS.xsd is returned. When looking for a respective bug report I occasionally found a schema at http://jira.codehaus.org/browse/CASTOR-1105 which is accepted by Castor, but should not: - references like type="string" are not valid if (a) there is no default namespace declaration xmlns="http://www.w3.org/2001/XMLSchema"; and (b) there is no user-defined type named "string" being defined in a schema without a targetNamespace (2) Attribute Declarations and attribute wildcards inherited from base type ======================================================================= Look at the following schema fragment: <xs:complexType name="C1"> <xs:sequence> <xs:element name="E1-C1" minOccurs="0" maxOccurs="27"/> </xs:sequence> <xs:attribute name="A1-C1" type="xs:float"/> </xs:complexType> <xs:complexType name="C2"> <xs:complexContent> <xs:extension base="C1"> <xs:choice> <xs:element name="E1-C2"/> </xs:choice> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="C3"> <xs:complexContent> <xs:restriction base="C1"> <xs:sequence> <xs:element name="E1-C1" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> The following should show up in the schema model: (a) Both derived complexTypes, C2 and C3 should have an attribute use with name "A1-C1" Castor does not return that! See "3.4.2 XML Representation of Complex Type Definitions" (http://www.w3.org/TR/xmlschema-1/#declare-type) e.g. under "Complex Type Definition with simple content Schema Component" you'll find <cite> {attribute uses} A _union_ of sets of attribute uses as follows ... 3 if the type definition ·resolved· to by the ·actual value· of the base [attribute] is a complex type definition, the {attribute uses} of that type definition, unless the <restriction> alternative is chosen, in which case some members of that type definition's {attribute uses} may not be included, ... </cite> In a similar way, an attribute wildcard is propagated to the properties of the derived type. (b) C2 should have an _effective_ content model which is a sequence containing two particles: - the first one is the sequence as defined in "C1", - the second is the choice as defined in "C2" "Complex Type Definition with complex content Schema Component" (3) Restricting an complexType with complexContent to complexType with simpleContent ================================================================================ - see "Schema Component Constraint: Derivation Valid (Restriction, Complex)" (http://www.w3.org/TR/xmlschema-1/#derivation-ok-restriction) 5.2.2.2 The {content type} of the {base type definition} must be elementOnly or mixed and have a particle which is ·emptiable· as defined in Particle Emptiable (§3.9.6). The following schema meets these constraints: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> <xs:complexType name="CT1" mixed="true"> <xs:sequence> <xs:element name="E1-CT1" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> <xs:complexType name="CT2"> <xs:simpleContent> <xs:restriction base="CT1"> <xs:simpleType> <xs:restriction base="xs:int"/> </xs:simpleType> </xs:restriction> </xs:simpleContent> </xs:complexType> </xs:schema> but is rejected by Castor with the following exception: complexType: CT2In a simpleContent when using restriction the base type must be a complexType whose base is a simpleType. at org.exolab.castor.xml.schema.reader.ComponentReader.error(ComponentReaderjava:213) at org.exolab.castor.xml.schema.reader.SchemaUnmarshaller.startElement(SchemaUnmarshaller.java:470) at org.exolab.castor.xml.schema.reader.Sax2ComponentReader.startElement(Sax2ComponentReader.java:253) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) .. ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] ------------------------------------------------- CODA has a new world-class consolidation package. Find out more about www.coda.com/ocra <http://www.coda.com/ocra> The information in this message is confidential and may be legally privileged. It may not be disclosed to, or used by, anyone other than the addressee. If you receive this message in error, please advise us immediately. Internet emails are not necessarily secure. CODA does not accept responsibility for changes to any email which occur after the email has been sent. Attachments to this email may contain software viruses, which could damage your systems. CODA has checked the attachments for viruses before sending, but you should virus-check them before opening. ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
