Understanding Schema in OpenDS#

Name Forms#

Name Forms may be used to define a mechanism for naming entries in the LDAP server. In particular, a Name Forms specifies one or more attributeTypes which must be present in the RDN of an LDAP Entry with a given STRUCTURAL object class, as well as zero or more attribute types which may optionally be present in the RDN.

Each STRUCTURAL object class defined in the server schema may be associated with at most one Name Form. If a Name Form is defined for a given structural object class, then the associated name form will be enforced for any Add Requestor Modify DN Request for entries containing that object class. If a structural object class is not associated with a name form, then any attribute type which is allowed to exist in the target entry may be used as a naming attribute type.

Name forms are not supported in the Sun Java System Directory Server, but are a new feature that is available in OpenDS.

The Name Form Description Format#

The name form description format is described in RFC 4512, section 4.1.7.2. The definition is as follows:

     NameFormDescription = LPAREN WSP
         numericoid                 ; object identifier
         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
         [ SP "DESC" SP qdstring ]  ; description
         [ SP "OBSOLETE" ]          ; not active
         SP "OC" SP oid             ; structural object class
         SP "MUST" SP oids          ; attribute types
         [ SP "MAY" SP oids ]       ; attribute types
         extensions WSP RPAREN      ; extensions

The elements of the name form description include:

• The numeric OID used to uniquely identify the Name Form in the server. Although the specification requires a numeric OID, OpenDS also allows a non-numeric OID for the purpose of convenience. In this case, the non-numeric OID should be the same as the name of the name form followed by the string "-oid".

• An optional set of human-readable names that may be used to refer to the Name Form. 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 present, then it should be enclosed in single quotation marks.
• An optional "OBSOLETE" flag that may be used to indicate whether the Name Form is active. If a name form is marked as "OBSOLETE", then it should not be in effect within the server, nor should it be possible to create any other elements that depend upon it.
• The name or OID of the structural object class with which the name form is associated.
• The name(s) or OID(s) of one or more attribute types that must be present in the RDN for any entry with the specified structural class. If there is only a single required attribute type, then only its name or OID needs to be given. If there are multiple required attribute types, then they should be separated by spaces and dollar signs, and the entire set of required attribute types should be enclosed in parentheses.
• The name(s) or OID(s) of zero or more attribute types that may optionally be present in the RDN for any entry with the specified structural class. If there is only a single optional attribute type, then only its name or OID needs to be given. If there are multiple optional attribute types, then they should be separated by spaces and dollar signs, and the entire set of optional attribute types should be enclosed in parentheses.
• An optional set of extensions for the name form. OpenDS currently uses the following extensions for name forms:
  • X-ORIGIN -- Provides information about where the name form 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 name form definition (this is generally used for internal purposes only and does not get exposed to clients).

For example, the following is the name form description for the uddiBusinessEntityNameForm name form defined in RFC 4403:

( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm'
          OC uddiBusinessEntity MUST ( uddiBusinessKey ) X-ORIGIN 'RFC 4403' )

In this case, the numeric OID is "1.3.6.1.1.10.15.1" and the human-readable name is "uddiBusinessEntityNameForm". Entries with the uddiBusinessEntity structural object class are required to use uddiBusinessKey as their only RDN attribute type. There is no description, nor are there any other attribute types that may optionally be included in the associated entries, and the name form is not marked "OBSOLETE".

The OpenDS Name Form Implementation#

As for attribute types and object classes, name forms can be defined purely from the schema configuration files, in this case using the name form description syntax detailed above. All name form instances in OpenDS are instances of the org.opends.server.types.NameForm class. Name form objects may be retrieved by the server schema using their OID, any of their human-readable names, or by the structural object class with which they are associated.

!! More Information There might be more information for this subject on one of the following:

• Understanding DIT Content Rules
• UnderstandingSchemaInOpenDS