You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Pete Geraghty (JIRA)" <xe...@xml.apache.org> on 2005/08/11 00:46:36 UTC
[jira] Created: (XERCESJ-1095) Schema with abstract type derived from concrete type can produce incorrect document validation.
Schema with abstract type derived from concrete type can produce incorrect document validation.
-----------------------------------------------------------------------------------------------
Key: XERCESJ-1095
URL: http://issues.apache.org/jira/browse/XERCESJ-1095
Project: Xerces2-J
Type: Bug
Components: XML Schema Structures
Versions: 2.5.0
Reporter: Pete Geraghty
Priority: Minor
An element in a document can be incorrectly reported as having error "cvc-type.2: The type definition cannot be abstract for element <Element>."
This can arise if the element declaration relates to a non-abstract type but there is an abstract type derived from that elsewhere in the schema. More particularly it will arise if the abstract type declaration is encountered prior to the non-abstract type when the schema is loaded.
For example, the problem arises with the following schema and document:
<?xml version="1.0"?>
<xsd:schema targetNamespace="XercesTest" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="XercesTest" >
<xsd:complexType name="AbstractExtendedType" abstract="true">
<xsd:complexContent>
<xsd:extension base="BaseConcreteType"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="BaseConcreteType">
<xsd:sequence>
<xsd:element name="A" type="xsd:string"/>
<xsd:element name="B" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="Element" type="BaseConcreteType"/>
</xsd:schema>
<?xml version="1.0"?>
<Element xmlns="XercesTest" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="XercesTest
C:\temp\XercesTest.xsd">
<A>String</A>
<B>String</B>
</Element>
The problem can be corrected by replacing lines 231-232 in org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.
Currently these lines say:
if (abstractAtt != null && abstractAtt.booleanValue())
fIsAbstract = true;
This means fIsAbstract is never changed from true to false. Should say:
fIsAbstract = abstractAtt == null ?
false : abstractAtt.booleanValue();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Resolved: (XERCESJ-1095) Schema with abstract type derived from concrete type can produce incorrect document validation.
Posted by "Michael Glavassevich (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1095?page=all ]
Michael Glavassevich resolved XERCESJ-1095:
-------------------------------------------
Resolution: Duplicate
This bug was also reported against Xerces 2.6.2 (see XERCESJ-1065) and was fixed [1] in Xerces 2.7.0.
[1] http://cvs.apache.org/viewcvs.cgi/xml-xerces/java/src/org/apache/xerces/impl/xs/traversers/XSDComplexTypeTraverser.java?r1=1.48&r2=1.49&diff_format=h
> Schema with abstract type derived from concrete type can produce incorrect document validation.
> -----------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1095
> URL: http://issues.apache.org/jira/browse/XERCESJ-1095
> Project: Xerces2-J
> Type: Bug
> Components: XML Schema Structures
> Versions: 2.5.0
> Reporter: Pete Geraghty
> Priority: Minor
>
> An element in a document can be incorrectly reported as having error "cvc-type.2: The type definition cannot be abstract for element <Element>."
> This can arise if the element declaration relates to a non-abstract type but there is an abstract type derived from that elsewhere in the schema. More particularly it will arise if the abstract type declaration is encountered prior to the non-abstract type when the schema is loaded.
> For example, the problem arises with the following schema and document:
> <?xml version="1.0"?>
> <xsd:schema targetNamespace="XercesTest" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="XercesTest" >
> <xsd:complexType name="AbstractExtendedType" abstract="true">
> <xsd:complexContent>
> <xsd:extension base="BaseConcreteType"/>
> </xsd:complexContent>
> </xsd:complexType>
> <xsd:complexType name="BaseConcreteType">
> <xsd:sequence>
> <xsd:element name="A" type="xsd:string"/>
> <xsd:element name="B" type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
> <xsd:element name="Element" type="BaseConcreteType"/>
> </xsd:schema>
> <?xml version="1.0"?>
> <Element xmlns="XercesTest" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="XercesTest
> C:\temp\XercesTest.xsd">
> <A>String</A>
> <B>String</B>
> </Element>
> The problem can be corrected by replacing lines 231-232 in org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.
> Currently these lines say:
> if (abstractAtt != null && abstractAtt.booleanValue())
> fIsAbstract = true;
> This means fIsAbstract is never changed from true to false. Should say:
> fIsAbstract = abstractAtt == null ?
> false : abstractAtt.booleanValue();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org