GNOME Bugzilla – Bug 312957
key/keyref validation passes incorectly when root element has an attribute defined
Last modified: 2009-08-15 18:40:50 UTC
Please describe the problem: I have a simple xml schema that uses key/keyref to constrain identity. In the schema I have defined an attribute called name on the root element. When the optional name attribute is present in the root element an invalid xml file (invalid keyref value) passes validation. If the root element name attribute is removed from the xml the validation fails as expected. The behaviour is consistent between xmllint and my own application which calls the libxml2 API directly. As an aside, xmlspy validates the file correctly whether the root element attribute is present or not. Steps to reproduce: 1. xmllint -noout -schema test.xsd test.xml 2. "test.xml validates" 3. Remove the root element attribute Name="test" 4. xmllint -noout -schema test.xsd test.xml 5. test.xml:2: element family: Schemas validity error : Element 'family': No match found for key-sequence ['annie'] of key reference 'sibling_key_ref'. test.xml fails to validate: 1877 Actual results: As above. Expected results: I expect the validation error reported in step 5 to be reported whether or not the root element attribute is present. Does this happen every time? Yes Other information: <?xml version="1.0" encoding="ISO-8859-1"?> <family xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="test.xsd" name="test"> <siblings> <sibling name="gill"/> </siblings> <sisters> <sister name="gill"/> <sister name="annie"/> </sisters> </family> <?xml version="1.0" encoding="ISO-8859-1"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="family" type="family_type"> <xs:key name="sibling_key"> <xs:selector xpath="siblings/sibling"/> <xs:field xpath="@name"/> </xs:key> <xs:keyref name="sibling_key_ref" refer="sibling_key"> <xs:selector xpath="sisters/sister"/> <xs:field xpath="@name"/> </xs:keyref> </xs:element> <xs:complexType name="family_type"> <xs:sequence> <xs:element name="siblings" type="siblings_type" /> <xs:element name="sisters" type="sisters_type" /> </xs:sequence> <xs:attribute name="name" type="xs:string"/> </xs:complexType> <xs:complexType name="siblings_type"> <xs:sequence> <xs:element name="sibling" type="sibling_type" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="sisters_type"> <xs:sequence> <xs:element name="sister" type="sister_type" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="sibling_type"> <xs:attribute name="name" type="xs:string"/> </xs:complexType> <xs:complexType name="sister_type"> <xs:attribute name="name" type="xs:string"/> </xs:complexType> </xs:schema>
Created attachment 50426 [details] Test schema.
Created attachment 50427 [details] Test xml.
Fixed in CVS head, xmlschemas.c revision 1.165. Streaming XPath states were not popped in every case in xmlSchemaVAttributesComplex(), thus failed to resolve correctly for subsequent input. Thanks for this report! Seems like IDCs still did not work in many cases for real life scenarios in Libxml2 2.6.20. The funny thing is that this obvious scenario is not covered by the W3C XML Schema test suite. I added your test to the regression tests.
This should be closed by release of libxml2-2.6.21, thanks, Daniel