Overview#
Object Classes#
Object classes are essentially named sets of attribute types that may be used to control the type of data that may be stored in entries. Note that the terms "object class" and "objectclass" (i.e., with and without a space between the words) are generally used interchangably.
The Object Class Description Format#
The object class description format is described in RFC 4512
, section 4.1.1. The definition is as follows:
ObjectClassDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oids ] ; superior object classes
[ SP kind ] ; kind of class
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
The elements of the object class description include:
The numeric OID used to uniquely identify the object class in the server. Although the specification requires a numeric OID, OpenDS also allows a non-numeric OID for the purpose of convenience and better compatibility with the Sun Java System Directory Server. In this case, the non-numeric OID should be the same as the name of the object class followed by the string "-oid".
- An optional set of human-readable names that may be used to refer to the object class. If there is a single name, then it should be enclosed in single quotes. If there are multiple names, then they should each be enclosed in single quotes separated by spaces and the entire set of names should be enclosed in parentheses.
- An optional human-readable description. If there is a description, then it should be enclosed in single quotation marks.
- An optional "OBSOLETE" flag that may be used to indicate whether the object class is active. If an object class is marked as "OBSOLETE", then it should not be referenced by any new elements created in the server.
- An optional set of superior class(es) for the object class. Note that although technically the specification allows an object class to have multiple superior classes, OpenDS currently only supports a single superior class. In this case, the "SUP" keyword should be followed by a space and the name or OID of the superior class. If there are multiple superior classes, then they should be separated by dollar signs and the entire set of superior classes should be enclosed in parentheses.
- An optional keyword that specifies the kind of object class that is being defined. If this is specified, then it must be one of "ABSTRACT", "STRUCTURAL", or "AUXILIARY". If no value is specified, then the object class will be considered "STRUCTURAL".
- An optional set of attribute types for attributes that are required to be present (i.e., have at least one value) in entries with that object class. If there is only a single required attribute, then the "MUST" keyword should be followed by the name or OID of that attribute type. If there are multiple required attribute types, then they should be separated by dollar signs and the entire set of required attribute types should be enclosed in parentheses.
- An optional set of optional attribute types for attributes that are allowed (but not required) to be present in entries with that object class. If there is only a single optional attribute, then the "MAY" keyword should be followed by the name or OID of that attribute type. If there are multiple optional attribute types, then they should be separated by dollar signs and the entire set of optional attribute types should be enclosed in parentheses.
- An optional set of extensions for the object class. OpenDS currently uses the following extensions for object classes:
- X-ORIGIN -- Provides information about where the object class is defined (e.g., whether it came from a particular RFC or Internet Draft, is defined within the OpenDS project, etc.).
- X-SCHEMA-FILE -- Indicates which schema file contains the object class definition (this is generally used for internal purposes only and does not get exposed to clients).
For example, the following is the object class description for the standard person object class:
( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description )
X-ORIGIN 'RFC 2256' )
In this case, the OID is "2.5.6.6". There is a single human-readable name of "person". The superior class is "top". The kind is "STRUCTURAL". Any entry containing the person object class will be required to include the sn and cn attributes, and will be allowed to include the userPassword, telephoneNumber, seeAlso, and description attributes. The object class definition was taken from RFC 2256. There is no description, and the object class is not considered "OBSOLETE".
Object Class Kinds#
As described above, all object classes must have a kind of either "ABSTRACT", "STRUCTURAL", or "AUXILIARY". These object class kinds may be described as follows:
- Abstract object classes are only intended to be extended by other object classes. An entry must not contain any abstract class unless it also contains a structural or auxiliary class that dervies from that abstract class (i.e., includes a non-abstract object class which has the abstract class in its inheritance chain). All entries must contain at least the "top" abstract object class, in the inheritance chain for their structural class. They may or may not contain other abstract classes in the inheritance chains for their structural class or any of their auxiliary classes.
- Structural object classes are intended to define the crux of what an entry represents. Every entry must include exactly one structural object class chain, and the root of that chain must ultimately be the "top" abstract object class. The structural object class for an entry is not allowed to be changed.
- Auxiliary object classes are intended to define additional qualities of entries. An entry may contain zero or more auxiliary classes, and the set of auxiliary classes associated with an entry may change over time.
The model represented by object class kinds translates very neatly to the model used by the Java programming language. Abstract LDAP object classes map directly to Java abstract classes, auxiliary LDAP object classes map directly to Java interfaces, and structural LDAP object classes map directly to Java concrete (non-abstact) classes. Just as Java classes must extend exactly one superclass but can implement any number of interfaces, so must LDAP entries contain exactly one structural class chain but can include any number of auxiliary class chains. Similarly, just as it is not possible to directly instantiate an abstract Java class, it is also not possible to create an LDAP entry containing only abstract object classes.
Note that the Sun Java System Directory Server has never enforced many of the restrictions noted here around object class kinds. In particular, it would allow the creation of entries that did not contain any structural object class chain, and would also allow the creation of entries containing multiple structural object class chains. This means that some deployments using the Sun Java System Directory Server may contain entries that violate this constraint. OpenDS will not allow this behavior by default, but for the sake of compatibility with existing Sun Java System Directory Server deployments, it will be possible to configure OpenDS to allow entries to violate this constraint, optionally writing a message to the server's error log each time this condition is detected. Note, however, that if there are entries that do not contain exactly one structural object class, then some schema elements like name forms and DIT content rules which depend on this constraint may not work as expected in all cases.
Object Class Inheritance#
As specified in the above description, object classes can have zero or more superior classes. If an object class references a superior class, then all of the required and optional attributes associated with that superior class are also associated with the subordinate class.
The following restrictions exist for object class inheritance:
- Abstract object classes may only inherit from other abstract classes. They may not be subordinate to structural or auxiliary classes.
- Structural object classes may only inherit from abstract classes or other structural classes. They may not be subordinate to auxiliary object classes.
- Auxiliary object classes may only inherit from abstract classes or other auxiliary classes. They may not be subordinate to structural object classes.
- All structural object classes must ultimately inherit from the top abstract object class. The net effect of this is that every entry in the server must include the top object class, and as a result must also include the objectClass attribute type which is required by the top object class).