XSD复杂类型继承中属性限制报错问题求助

Got it, let's break down what's going wrong here. The error you're seeing happens because you're trying to restrict the Type attribute in your derived VaultServiceConfigurationObject using xs:string, but the base VaultObject's Type attribute isn't a plain xs:string—it's a custom restricted string type with an enumeration. XSD enforces that when you restrict an inherited attribute, the derived attribute's type must be a valid restriction of the base attribute's type, and xs:string doesn't fit that rule here.

The Fix #

First, let's clean up the base type by extracting the enumeration into a reusable named simple type. This makes the base attribute's type explicit and easier to reference in the derived type. Then, in the derived type, we don't need to specify type="xs:string" at all—we just lock the value to one of the valid enumeration options using fixed, while keeping the inherited type intact.

Here's the corrected XSD code:

<?xml version="1.0" encoding="utf-8" ?>
<!--Created with Liquid Studio 2020-->
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <!-- Reusable enumeration type for VaultObject Type attribute -->
    <xs:simpleType name="VaultObjectType">
        <xs:restriction base="xs:string">
            <xs:enumeration value="Merge" />
            <xs:enumeration value="ServiceConfiguration" />
        </xs:restriction>
    </xs:simpleType>

    <xs:complexType name="VaultObject">
        <xs:sequence>
            <xs:annotation>
                <xs:documentation>Allows for derived object to have a sequence of elements</xs:documentation>
            </xs:annotation>
        </xs:sequence>
        <xs:attribute name="Type" type="VaultObjectType" use="required">
            <xs:annotation>
                <xs:documentation>This is the list of possible vault objects. Derived objects need to lock this down to the object type they represent.</xs:documentation>
            </xs:annotation>
        </xs:attribute>
        <xs:anyAttribute />
    </xs:complexType>

    <xs:complexType name="VaultServiceConfigurationObject">
        <xs:complexContent>
            <xs:restriction base="VaultObject">
                <!-- No need to specify type here; it inherits VaultObjectType from the base -->
                <xs:attribute name="Type" fixed="ServiceConfiguration" use="required">
                    <xs:annotation>
                        <xs:documentation xml:lang="EN">This property is inherited from VaultObject, but is locked down to the fixed value of "ServiceConfiguration"</xs:documentation>
                    </xs:annotation>
                </xs:attribute>
                <xs:attribute name="ServiceType">
                    <xs:annotation>
                        <xs:documentation xml:lang="EN">The list of possible service types we support. Derived service definitions need to lock this down to a single value in their own type.</xs:documentation>
                    </xs:annotation>
                    <xs:simpleType>
                        <xs:restriction base="xs:string">
                            <xs:enumeration value="SystemA" />
                            <xs:enumeration value="SystemB" />
                        </xs:restriction>
                    </xs:simpleType>
                </xs:attribute>
                <xs:attribute name="Name" type="xs:string" use="required">
                    <xs:annotation>
                        <xs:documentation xml:lang="EN">Every service needs to be uniquely named. Even between different service types.</xs:documentation>
                    </xs:annotation>
                </xs:attribute>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
</xs:schema>

Why This Works #

• By extracting the enumeration into VaultObjectType, we make the base attribute's type explicit. The derived type's Type attribute inherits this type automatically when we restrict the base complex type.
• Setting fixed="ServiceConfiguration" is valid because this value is already part of the base enumeration—XSD sees this as a valid restriction (narrowing the allowed values to one specific option from the base set).
• We removed the type="xs:string" that was causing the mismatch, so now the derived attribute's type matches the base attribute's type exactly, just with a fixed value.

This should resolve the error in your text editor while keeping the behavior Liquid XML Designer already recognized.

内容的提问来源于stack exchange，提问作者zu1b