[
https://issues.apache.org/jira/browse/XERCESC-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543504
]
Anton Nikolaevsky commented on XERCESC-697:
-------------------------------------------
2 Frank Gierschner
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#section-Constraints-on-XML-Representations-of-Complex-Type-Definitions
...
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;
> Incorrect Schema Validation Failure When Redefining Complex Type with Simple
> Content
> ------------------------------------------------------------------------------------
>
> Key: XERCESC-697
> URL: https://issues.apache.org/jira/browse/XERCESC-697
> Project: Xerces-C++
> Issue Type: Bug
> Components: Validating Parser (Schema) (Xerces 1.5 or up only)
> Affects Versions: 2.1.0
> Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Joe Misner
> Assignee: Xerces-C Developers Mailing List
> Attachments: TraverseSchema.cpp.595303.diff
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
