After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 609796 - Failure to validate optional element in complex type extension
Failure to validate optional element in complex type extension
Status: RESOLVED FIXED
Product: libxml2
Classification: Platform
Component: general
2.7.6
Other Linux
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2010-02-12 22:43 UTC by Michael Romer
Modified: 2012-05-11 09:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sample schema and instance document exemplifying failed validation (683 bytes, application/x-gzip)
2010-02-12 22:43 UTC, Michael Romer
  Details
complex type extension cardinality mismatch (1.17 KB, patch)
2011-03-28 16:16 UTC, Remi Gacogne
none Details | Review
Sample xml test case (311 bytes, text/xml)
2011-03-28 16:21 UTC, Remi Gacogne
  Details
Sample XSD test case (711 bytes, application/xml)
2011-03-28 16:21 UTC, Remi Gacogne
  Details

Description Michael Romer 2010-02-12 22:43:31 UTC
Created attachment 153671 [details]
Sample schema and instance document exemplifying failed validation

Libxml2 fails to validate an instance document against a schema if an element whose type is a complex extension of some base type with an optional child element and that child element is not specified in the instance document.  For example, suppose I have some complex type BaseType that is defined to have one child element in a sequence group that has minOccurs set to 0:


<xs:complexType name="BaseType">
    <xs:sequence minOccurs="0">
        <xs:element name="OptionalElementInBase">
            <xs:complexType>
                <xs:attribute name="value" type="xs:string" use="required"/>
            </xs:complexType>
        </xs:element>
    </xs:sequence>
</xs:complexType>


Then say I have some other complex type DerivedType that is a complex extension of BaseType.  It adds another element that may or may not be optional like so:


<xs:complexType name="DerivedType">
    <xs:complexContent>
        <xs:extension base="BaseType">
            <xs:sequence minOccurs="0">
                <xs:element name="OptionalElementInDerived">
                    <xs:complexType>
                        <xs:attribute name="value" type="xs:string" use="required"/>
                    </xs:complexType>
                </xs:element>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>


And then for example's sake let's say in my schema I've also declared a top level element whose type is DerivedType like so:


<xs:element name="Derived" type="DerivedType"/>


Now I also have an instance document whose root element is Derived and specify it like this (I'm leaving out the schema location attributes for brevity sake):


<Derived>
    <OptionalElementInDerived value="bar"/>
</Derived>


Running xmllint like this will then cause the above instance document to fail.


$ xmllint --schema <my schema> <my instance document>


However if I modify the instance document like so, then xmllint successfully validates the document:


<Derived>
    <OptionalElementInBase value="foo"/>
    <OptionalElementInDerived value="bar"/>
</Derived>


I have attached a tarball that has a schema and instance document that exemplifies this behavior.  Simply extracting it and running xmllint at the command line will demonstrate the problem.  I am running libxml2 2.7.6 on Red Hat Enterprise Linux 5.4.  For comparison, validation within Oxygen XML Editor using the Saxon-SA validator works just fine.  Any help would be greatly appreciated in this matter.  Thanks.
Comment 1 Michael Romer 2010-02-15 15:15:51 UTC
As a workaround, it appears that the minOccurs="0" occurrence constraint can be moved from the <xs:sequence> element to the OptionalElementInBase's <xs:element> in the type definition for BaseType, and then validation will work as expected.
Comment 2 Remi Gacogne 2011-03-28 16:16:04 UTC
Created attachment 184476 [details] [review]
complex type extension cardinality mismatch
Comment 3 Remi Gacogne 2011-03-28 16:20:12 UTC
Hello,

I have sent this patch to the libxml2 mailing list in November for another issue, and it seems to fix this bug as well.

My issue was: 
"It seems that there is an issue regarding the inheritance of cardinality in complex type extension.
I have attached a simple XML file with the corresponding XSD, where "ItemWithNumber" is a complexType extending the base type "Item". "Item" contains a unbounded sequence of "Name" elements, but libxml2/xmllint does not allow more than one "Name" in the elements  of type "ItemWithNumber" present in the XML. I may be mistaken, but I think it is not the expected behavior."

The related XML and XSD files are attached below.
Comment 4 Remi Gacogne 2011-03-28 16:21:23 UTC
Created attachment 184478 [details]
Sample xml test case
Comment 5 Remi Gacogne 2011-03-28 16:21:46 UTC
Created attachment 184479 [details]
Sample XSD test case
Comment 6 Remi Gacogne 2012-02-29 10:40:58 UTC
Hi,

I cannot change the Version field, but this bug still exists in 2.7.8.

Any chance to have it fixed in the next release ? :)

Thanks,
Comment 7 Daniel Veillard 2012-05-11 09:13:49 UTC
Hi Remi,

thanks for the patch, this makes sense, I also added
the example to the regression tests and commited:

http://git.gnome.org/browse/libxml2/commit/?id=4609e6c980b256e4115d4b7e1227f59870465995

 thanks a lot !

Daniel