!!!Understanding Schema in OpenDS

%%(text-align: right;)
[Return to Contents|UnderstandingSchemaInOpenDS]\\
[Previous: Object Classes|UnderstandingObjectClasses]\\
[Next: DIT Content Rules|Understanding DIT Content Rules]
%%

!! [Name Forms]

%%information
Not all [LDAP Server Implementations] Support [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 Request]or [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|https://opends.dev.java.net/public/standards/rfc4512.txt], 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|https://opends.dev.java.net/public/standards/rfc4403.txt]:

{{{
( 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. 

%%(text-align: right;)
[Return to Contents|UnderstandingSchemaInOpenDS]\\
[Previous: Object Classes|UnderstandingObjectClasses]\\
[Next: DIT Content Rules|Understanding DIT Content Rules]
%%!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]