DIT Structure Rules may be used to define the allowed hierarchical structure of the directory data. In particular, DIT Structure Rules make it possible to specify what types of entries will be allowed to exist as immediate Subordinate of entries with a specified structural object class (e.g., only entries with the inetOrgPerson structural class may be immediate children of entries with an organizationalUnit structural object class).
DIT Structure Rules are themselves hierarchical. Each DIT Structure Rules is assigned a rule ID, which is an integer value, and is also associated with a name form (which in turn links it to a structural object class).
DIT Structure Rules may also reference one or more superior DIT Structure Rules, and this provides the mechanism for controlling the data hierarchy. If a DIT Structure Rules does not specify any superior rules, then entries containing its associated structural object class are allowed to exist at the root of the associated schema. If it does specify one or more superior rules, then entries with its associated structural object class will only be allowed to exist below entries containing the structural object class of one of those superior rules.
The DIT Structure Rules Description Format#
DITStructureRuleDescription = LPAREN WSP ruleid ; rule identifier [ SP "NAME" SP qdescrs ] ; short names (descriptors) [ SP "DESC" SP qdstring ] ; description [ SP "OBSOLETE" ] ; not active SP "FORM" SP oid ; NameForm [ SP "SUP" ruleids ] ; superior rules extensions WSP RPAREN ; extensions ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN ) ruleidlist = ruleid *( SP ruleid ) ruleid = number
The elements of the DIT Structure Rules description include:
- The integer rule ID assigned to the DIT structure rule. It must be unique among all other DIT Structure Rules in the schema.
- An optional set of human-readable names that may be used to refer to the DIT Structure Rules. 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 a description is provided, then it should be enclosed in single quotes.
- An optional OBSOLETE flag that may be used to indicate whether the DIT structure rule is active. If it is marked "OBSOLETE", then it should not be taken into account when entries are created or moved.
- The name or OID of the name form with which the DIT Structure Rules is associated. As mentioned above, the name form associates the DIT structure rule with a structural object class.
- An optional set of superior rule IDs for the DIT Structure Rules. If there are multiple superior rule IDs, then they should be separated by spaces and the entire set of superior rule IDs should be enclosed in parentheses. It is permissible for multiple DIT structure rules to use overlapping sets of superior rule IDs.
- An optional set of extensions for the DIT structure rule.
- X-ORIGIN -- Provides information about where the DIT structure rule is defined (e.g., whether it came from a particular RFC or Internet Draft, is defined within the OpenDS project,
- X-SCHEMA-FILE -- Indicates which schema file contains the DIT Structure Rules definition (this is generally used for internal purposes only and does not get exposed to clients).
For example, the following is the DIT structure rule definition for the uddiContactStructureRule DIT structure rule:
( 2 NAME 'uddiContactStructureRule' FORM uddiContactNameForm SUP ( 1 ) X-ORIGIN 'RFC 4403' )
In this case, the rule ID is "2", and the human-readable name is "uddiContactStructureRule". It is associated with the uddiContactNameForm name form (which in turn links it to the uddiContact object class), and it has a superior rule ID of "1". It was defined in RFC 4403. It does not have a description, nor is it marked "OBSOLETE".
DIT Structure Rules and Multiple Schemas#
DIT Structure Rules may provide a mechanism for placing constraints on the server hierarchy, but in order to maximize their utility it may be necessary to use them in conjunction with support for multiple schemas. For example, consider a directory with a naming context of "dc=example,dc=com", below which are two branches: "ou=People,dc=example,dc=com" and "ou=Groups,dc=example,dc=com". If you wish to only allow inetOrgPerson entries below the "ou=People" branch, and only groupOfNames entries below the "ou=Groups" branch, then that can only be fully accomplished if there are different schemas that govern the "ou=People" and "ou=Groups" branches.
If there were a single schema governing the entire server, then you can imagine that it would have four DIT structure rules:
- ( 1 NAME 'domainStructureRule' FORM 'domainNameForm' )
- ( 2 NAME 'organizationalUnitStructureRule' FORM 'organizationalUnitNameForm' SUP 1 )
- ( 3 NAME 'inetOrgPersonStructureRule' FORM 'inetOrgPersonNameForm' SUP 2 )
- ( 4 NAME 'groupOfNamesStructureRule' FORM 'groupOfNamesNameForm' SUP 2 )
This set of DIT structure rules would allow the structure described above, but it would also allow the creation of group entries below the "ou=People" branch and the creation of user entries below the "ou=Gropus" branch. The only way to prevent that using DIT structure rules would be to define separate schemas for the "ou=People" and "ou=Groups" branches and only define the "inetOrgPersonStructureRule" rule in the schema for the "ou=People" branch, and only define the "groupOfNamesStructureRule" rule in the schema for the "ou=Groups" branch.
More information about the potential use for multiple schemas in OpenDS will be described in a later section.