One attribute type can reference another as its superior class. This has two primary effects:
The matching rule and attribute syntax specifications from the superior attribute type can be inherited by the subordinate type if the subordinate does not override the superior definition. For example, if the superior attribute type uses the IA5 String syntax, then the subordinate attribute type also uses the IA5 String syntax unless its definition overrides that by specifying an alternate syntax. According to the specification in RFC 4512, section 2.5.1, an attribute type can have a different syntax than its superior type only if the syntax for the subordinate type is a refinement of (that is, allows a subset of the values of) the syntax for the superior attribute type.
The OID, any of the human-readable names associated with the superior attribute type, or both can be used to collectively reference all of the subordinate types. For example, the name attribute type is referenced as the superior type for the cn, sn, c, l, st, o, ou, title, givenName, initials, generationQualifier, and dmdName attribute types. Therefore, a filter of (name=test)should match an entry if any attribute with one of those types has a value of test.
A subordinate attribute type cannot have a different usage than its superior type. That is, if the superior type is userApplications, then the subordinate type must also be userApplications. Similarly, if a superior type is declared COLLECTIVE, then the subtype must also be COLLECTIVE, but if the superior type is not COLLECTIVE, then the subordinate type must also not be COLLECTIVE.