DO NOT REPLY [Bug 14000] New: - Incorrect Schema Validation Failure When Redefining Complex Type with Simple Content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14000>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14000

Incorrect Schema Validation Failure When Redefining Complex Type with Simple Content

           Summary: Incorrect Schema Validation Failure When Redefining
                    Complex Type with Simple Content
           Product: Xerces-C++
           Version: 2.1.0
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Validating Parser (Schema) (Xerces 1.5 or up only)
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]