GNOME Bugzilla – Bug 341337
Optional attributes are not being defaulted to values specified in schema
Last modified: 2006-05-11 16:27:58 UTC
Please describe the problem: Optional attributes declared to have default values in W3C XMLSchemas are not added to the xmlDoc stucture when they arent specified in an instance document of that schema. Strangely, the program knows about the defualt value( stored in the variable iattr->decl at some point in the xmlSchemaVAttributesComplex() function ), just an error in the logic makes sure the code never gets run that creates the new attribute node to sit in for the missing attribute. Steps to reproduce: 1. Create a schema that has elements with optional attributes with a default specified 2. call xmlSchemaSetValidOptions( schema_validation_context, XML_SCHEMA_VAL_VC_I_CREATE ); 3. validate an instance document that leaves out the optional attributes 4. xmlGetProp( node_with_optional_attributes, defaulted_attribute_name ) returns null Actual results: xmlGetProp( node_with_optional_attributes, defaulted_attribute_name ) returns null Expected results: xmlGetProp( node_with_optional_attributes, defaulted_attribute_name ) returns the string representation of the default value Does this happen every time? yes Other information: ============Schema================= <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" xml:lang="en"> <xs:element name="DefaultAttributeTest"> <xs:complexType> <xs:attribute name="optional1" type="xs:integer" use="optional" default="1"/> <xs:attribute name="optional2" type="xs:integer" use="optional" default="2"/> <xs:attribute name="optional3" type="xs:integer" use="optional" default="3"/> <xs:attribute name="override1000with2" type="xs:integer" use="optional" default="1000"/> <xs:attribute name="optional4" type="xs:integer" use="optional" default="4"/> <xs:attribute name="optional5" type="xs:integer" use="optional" default="5"/> <xs:attribute name="optional6" type="xs:integer" use="optional" default="6"/> <xs:attribute name="optional7" type="xs:integer" use="optional" default="7"/> </xs:complexType> </xs:element> </xs:schema> =================================== ============Instance=============== <?xml version="1.0" encoding="UTF-8"?> <DefaultAttributeTest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="default-attributes.xsd" override1000with2="2"/> =================================== I tracked down the problem to here where defualt values get filled in. http://cvs.gnome.org/viewcvs/*checkout*/libxml2/xmlschemas.c?rev=1.201 iattr->node on an optional attribute that isnt present is always null. Whereever this "iattr" struct is getting built they forgot to build a(n attribute)node for it. iattr->decl->defValue has the defualt value needed, but I'm too lost in the logic of the code to provide a fix of my own. static int xmlSchemaVAttributesComplex(xmlSchemaValidCtxtPtr vctxt) line 25137 of schemas.c /* * PSVI: Add the default attribute to the current element. * VAL TODO: Should we use the *normalized* value? This currently * uses the *initial* value. */ if ((vctxt->options & XML_SCHEMA_VAL_VC_I_CREATE) && (iattr->node != NULL) && (iattr->node->doc != NULL)) { xmlChar *normValue; const xmlChar *value; value = iattr->value; /* * Normalize the value. */ normValue = xmlSchemaNormalizeValue(iattr->typeDef, iattr->value); if (normValue != NULL) value = BAD_CAST normValue; if (iattr->nsName == NULL) { if (xmlNewProp(iattr->node->parent, iattr->localName, value) == NULL) { VERROR_INT("xmlSchemaVAttributesComplex", "callling xmlNewProp()"); if (normValue != NULL) xmlFree(normValue);
Fixed in CVS, xmlschemas.c, revision 1.202. The code expected a node (xmlNodePtr) on the info for a non-existent default attribute, which clearly cannot be expected, since the attribute does not exist. I can only guess that this sneaked in while trying to eliminate the query for the owner-element, which is unavoidable actually. Note that creation of default attributes won't have an effect if validating via SAX/XMLReader; i.e., the processor won't fire additional start-attribute events (I'm not even sure if Libxml2 has such a SAX-event; I think it hands them all over in the start-element event). Thanks for the report!