[ http://nagoya.apache.org/jira/browse/XERCESC-697?page=comments#action_55889 ] Frank Gierschner commented on XERCESC-697: ------------------------------------------
Hi all @ xerces-c-dev. As I found this bug report after encountering the same problems on my own still appearing with Xerces C++ 2.3.0 and 2.6.0 I just add some comments I initially wanted to send as a bug report here: >> I am trying to create an XSD for new needs of my application using so-called 'best practises' from www.w3c.org-linked sites but I encountered some problems with Xerces-C++ parsing / validating it. The Readme section of the Xerces-C++ (versions 2.3.0/2.6.0) HTML documentation states that Xerces-C++ conforms to the >>XML Schema Part 1: Structure <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>, W3C Recommendation 2 May 2001<<. Within this site the subsection http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#element-simpleContent describes the usage of 'simpleContent' within 'complexType' allowing 'restriction' to be used as well as 'extension' (latter works well with Xerces-C++). This does not seem to be supported of both of the above mentioned versions of Xerces-C++. When trying to 'domprint -v=always -n -s -f -wfpp=on instancetest.xml' an adapted xml file found under the "best practises" link http://www.xfront.com/HermaphroditeTypes.zip (note that the files are from 2001) which was linked from www.w3c.org (see below) returns with outputs like: Message: The type 'xsd:string' is a simple type. It cannot be used in a derivation by RESTRICTION for a complexType. I suppose that this is in error with the W3C recommendation Xerces-C stated to conform to. Some links for further reference: Specification 2004: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-simpleContent Specification 2001: http://www.w3.org/TR/xmlschema-1/#element-simpleContent How I found the xml/xsd files: Gone to http://www.w3c.org/XML/Schema#usage found link to http://www.xfront.com/ chosen link to 'best practises': http://www.xfront.com/BestPracticesHomepage.html and therein to zip with XSD/XML files http://www.xfront.com/HermaphroditeTypes.zip to change in instance.xml before parsing / validating xsi:noNamespaceSchemaLocation=".\ExempleFinal.xsd"> << As this initial bug report is about 2 years old I would appreciate to be informed if and when it will be fixed. Greetings Frank > Incorrect Schema Validation Failure When Redefining Complex Type with Simple > Content > ------------------------------------------------------------------------------------ > > Key: XERCESC-697 > URL: http://nagoya.apache.org/jira/browse/XERCESC-697 > Project: Xerces-C++ > Type: Bug > Components: Validating Parser (Schema) (Xerces 1.5 or up only) > Versions: 2.1.0 > Environment: Operating System: Windows XP > Platform: PC > Reporter: Joe Misner > Assignee: Xerces-C Developers Mailing List > > Running the SAXCount and DOMCount sample programs with "-n -s -f" options > resulted in the following error diagnostic (one of several similar ones): > Error at file C:\IVANSWork\NETParserBugs\DupDef\AcmeAdaptor_TagExt.xsd, line > 9, char 45 > Message: The type 'ACORDAddressType_rdfn' is a simple type. It cannot be > used in a derivation by RESTRICTION for a complexType > The line identified in the error points to the following definition: > <xs:redefine schemaLocation="acordV12_TagExt.xsd"> > <xs:complexType name="ACORDAddressType"> > <xs:simpleContent> > <xs:restriction base="ACORDAddressType"> > <xs:enumeration value="BillingAddress"/> > <xs:enumeration value="GaragingAddress"/> > <xs:enumeration value="MailingAddress"/> > <xs:enumeration value="StreetAddress"/> > </xs:restriction> > </xs:simpleContent> > </xs:complexType> > </xs:redfine> > > The original schema being redefined contains the following: > <xsd:complexType name="AddressType" abstract="true"> > <xsd:simpleContent> > <xsd:extension base="OpenEnum_NoID"> > <xsd:attribute name="id" type="ID"/> > <xsd:attribute name="CodeListRef" type="IDREF"/> > </xsd:extension> > </xsd:simpleContent> > </xsd:complexType> > <xsd:complexType name="ACORDAddressType"> > <xsd:simpleContent> > <xsd:restriction base="AddressType"> > <xsd:enumeration value="BillingAddress"/> > <xsd:enumeration value="DataBackupStorageAddress"/> > <xsd:enumeration value="DuplicateRecordsAddress"/> > <xsd:enumeration value="FurthestTerminalAddress"/> > <xsd:enumeration value="GaragingAddress"/> > <xsd:enumeration value="MailingAddress"/> > <xsd:enumeration value="PointOfDepartureAddress"/> > <xsd:enumeration value="PointOfDestinationAddress"/> > <xsd:enumeration value="PreviousAddress"/> > <xsd:enumeration value="ShippingAddress"/> > <xsd:enumeration value="SoftwareBackupStorageAddress"/> > <xsd:enumeration value="StreetAddress"/> > </xsd:restriction> > </xsd:simpleContent> > </xsd:complexType> > Clearly the diagnostic message is inaccurate. The ACORDAddressType is NOT a > simple type (in either schema); it is a complex type with simple content. It > should be possible for the redefining schema to do simple-content > restrictions, in this case limiting the values of the enumeration to a > smaller > subset than is given the original schema. > FYI, the XSV, Xerces-J, and MSXML schema validators accept this syntax with > no > problem and apply it correctly to instance documents. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
