Actually, XML schema language can express constraints like that (a name authority must have only name variants with the same type attribute), but the technique is aesthetically...dubious. In English, you give each descriptor an attribute with a fixed value that defines its equivalence class (e.g. titles and name+title combinations might be variants of each other, likewise geographic and hierarchicalGeographic, so they're in the same class). Then use keys and keyrefs to enforce the constraint that descriptors in different equivalence classes can't appear in the same MADS record. Schema fragment: <xs:complexType name="madsType"> ... <xs:key name="eqclass-key"> <xs:selector xpath="mads:authority/*"/> <xs:field xpath="@eqclass"/> <xs:field xpath="@type"/> </xs:key> <xs:keyref name="same-eqclass" refer="mads:eqclass-key"> <xs:selector xpath="mads:variant/*"/> <xs:field xpath="@eqclass"/> <xs:field xpath="@type"/> </xs:keyref> </xs:complexType> <xs:complexType name="titleType"> ... <xs:attribute name="eqclass" fixed="titles"/> ... </xs:complexType> <xs:complexType name="nameTitleType"> ... <xs:attribute name="eqclass" fixed="titles"/> ... </xs:complexType> <xs:complexType name="titleType"> ... <xs:attribute name="eqclass" fixed="names"/> ... </xs:complexType> etc. >>> [log in to unmask] 12/17/04 7:18 PM >>> <snip> Not only does this make logical sense, it also allows one to much more finely-control validation. A person element thus cannot have an authorized name that is a corporate name, and an authorized name that is a person cannot have a variant that is a corporate name, or -- much worse -- a title.