XML schema unique constraint in a type rather than an element

Question

Is there a way of putting a unique constraint in the XML Schema 1.0 xs:complexType rather than xs:element? What I mean specifically is that I would like to create a unique keys list type that I could easily reuse in many places of the schema.

Something like this would be great:

<xs:complexType name="t_MyReusableUniqueKeysList">
        <xs:sequence>
            <xs:element name="GenericElementOfTheList" type="t_GenericElementOfTheList" minOccurs="1" maxOccurs="unbounded"/>
            <xs:unique name="uniqueCheck">
                    <xs:selector xpath="GenericElementOfTheList"/>
                    <xs:field xpath="GenericElementOfTheList_Key"/>
            </xs:unique>
        </xs:sequence>
</xs:complexType>

But it seems that it is not correct.

EDIT/EXPLANATION: I realize that I can wrap the code above around with xs:element to make it work but my naive understanding, as one of a XML Schema newbie, is that I won't be able to reuse it then in other Schemas (reuse = declare any element as t_MyReusableUniqueKeysList)?

Answer 1

No, you cannot associate identity constraints in XSD with types. In XSD, as in SQL, referential integrity is distinct from the type system.

[Postscript]. The second sentence of the preceding paragraph appears to need unpacking.

In SQL, each column in a table gets a datatype: integer, decimal number with 6 digits to the left of the decimal point and two to the right, varchar 80, date, fixed-length string of length 8, etc., etc. For each column, the table creator can also specify whether the column is allowed to be NULL or not. And each column can be a key, part of a key, a reference to a key in another table, or part of such a reference. The NOT NULL, PRIMARY KEY, SECONDARY KEY, and FOREIGN KEY ... REFERENCES ... constraints are all orthogonal to the type system: none of them is implied, or can be implied, by the type assigned to a column, and none of them requires a particular type. The referential integrity constraints are attached logically to columns (or sequences of columns) and not to types. In that sense, the referential integrity constraints of SQL are distinct from the type system.

(Note that I am focusing here on the relational core of SQL and ignoring the various additions and extensions made over the years. I have no idea whether the various additions made in SQL 99 and later behave this way or not.)

Similarly, in XSD the identity constraints (key, unique, and keyref) are as orthogonal to the type system as it was possible to make them. XSD types have (or: can have) names, and no type name implies the presence or absence of any identity constraint (except for the legacy ID and IDREF types). And conversely, identity constraints can be used with any type. The identity constraints of XSD are attached to elements, and not to types. The model of SQL was important here, both intellectually and from an implementation standpoint (since several major SQL vendors in the responsible WG were planning to support XSD in their SQL implementations -- as in fact most major SQL implementations now do).