Is redefinition of attribute values in extension allowed?

Does the official specification of XSD allow to re-define attribute values (with default/fixed) in derived types with <extension>? Both MSXML and Xerces-C allow this, but not libxml2 (does not accept the input XSD).

In the sample below, the "Parent" declares a attribute name without value, and the "Child" applies a fixed value to it.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:complexType name="Parent">
        <xs:sequence>
            <xs:element name="node1" type="xs:string"/>
        </xs:sequence>
        <xs:attribute name="name" type="xs:string"/>
    </xs:complexType>

    <xs:complexType name="Child">
        <xs:complexContent>
            <xs:extension base="Parent">
                <xs:sequence>
                    <xs:element name="node2" type="xs:string"/>
                </xs:sequence>
                <xs:attribute name="name" type="xs:string" fixed="value1"/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

    <xs:element name="Child" type="Child"/>
</xs:schema>

Solution

No, it's not valid. The general rule is that you can't extend and restrict in a single step; it needs to be done in two steps.

Saxon reports the error in a slightly different (and not very helpful) way:

Error on line 9 of test.xsd:
   Attribute @name appears more than once in attribute group

Yes, there's no explicit attribute group here, but every complex type has an implicit attribute group and that's what it's complaining about.

Looking at the spec, the way XSD 1.1 describes the rules is generally easier to follow than XSD 1.0, and in this case I don't think there is a substantive change.

In XSD 1.1 part 1, Section 3.4.2.4 Mapping Rule for Attribute Uses Property says that {attribute uses} is the union of the attributes from the base type and the extended type. "Union" isn't very clearly defined in the spec, but it generally means that you eliminate exact duplicates, and in this case the attribute definitions aren't exact duplicates because one has a "fixed" value and the other doesn't.

Then section 3.4.6.2 Derivation Valid (Extension) rule 1.2 says that:

B.{attribute uses} [must be] a subset of T.{attribute uses}. That is, for every attribute use U in B.{attribute uses}, there is an attribute use in T.{attribute uses} whose properties, recursively, are identical to those of U.

which fails in your case because the properties of the two attribute uses differ.